mirror of
https://github.com/koel/koel.git
synced 2026-04-26 01:06:00 +03:00
[GH-ISSUE #1781] "The MAC is invalid" after upgrade #984
Labels
No labels
Authentication
Dependencies
Documentation
Feature Request
Flac
Help Wanted
Installation/Setup
Integration
Mobile
PR Welcome
Pending Release
Performance
Playlist
S3
Search
Sync
[Pri] Low
[Pri] Normal
[Status] Keep Open
[Status] Needs Author Reply
[Status] Needs Review
[Status] Stale
[Status] Will Implement
[Type] Blessed
[Type] Bug
[Type] Duplicate
[Type] Enhancement
[Type] Help Request
[Type] Question
[Type] Task
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/koel-koel#984
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Mark-Shternberg on GitHub (Jul 12, 2024).
Original GitHub issue: https://github.com/koel/koel/issues/1781
Describe the bug
Error occurs after upgrade from v7.0.1 to v7.0.2 when browser sent get request (start page opening, but in console i see error 500 (trace log attached), and log in doesn't work)
I tried to deactivate Koel plus via CLI, thinking that it is a reason, but it's fail with same error
(at the same time
php artisan koel:init --no-assetsruns successfully)Environment
Additional context
Trace log:
@Mark-Shternberg commented on GitHub (Jul 13, 2024):
Problem solved by deactivate license via Lemon Squeezy, and activate again from CLI, but it's not normal for upgrade :)
@phanan commented on GitHub (Jul 13, 2024):
It certainly isn't, but I'm glad you got it solved! Since I can't reproduce it, I'm going to close the issue, but if anyone else reports the same error I'll look more into it.
@phanan commented on GitHub (Jul 13, 2024):
Hmm apparently the
APP_KEYchanged would cause this error. Did you perhaps change the app key somehow?@Mark-Shternberg commented on GitHub (Jul 13, 2024):
Yep, when i run
php artisan koel:init --no-assetsafter upgrade APP_KEY was recreated.BUT. I included it in my docker-compose.yml and upgrade from v7.0.2 to v7.0.3 fails again with this error
May be Lemon Squeezy somehow check MAC address of server, and when docker recreate container for upgrade assign it new MAC
@phanan commented on GitHub (Jul 13, 2024):
Hmm I doubt that's LemonSqueezy fault. Koel encrypts the license with
APP_KEY, so ifAPP_KEYis changed, the decryption will fail with the error (that's why you had to re-activate). What confuses me is,APP_KEYisn't supposed to be changed duringkoel:init, as the task checks for its existence before generating and populating a new one.I will look deeper into this matter. For now, sorry this happened to you, but I'm glad that the solution/workaround is manageable :)
@Mark-Shternberg commented on GitHub (Jul 13, 2024):
APP_KEYwas changed beacause after recreation of koel container it doesn't contain.env. And ifAPP_KEYwasn't explicitly appointed, Koel regenerate it. Here is part ofphp artisan koel:init --no-assetsoutput withoutAPP_KEYindocker-compose.yml:And another note: if i return old
APP_KEYand rerunphp artisan koel:init --no-assetserror occurs again anyway@phanan commented on GitHub (Jul 13, 2024):
Not sure I follow. Doesn't this mean whenever you recreate the container, you'll have to re-configure everything (database, keys, etc.) again?
@Mark-Shternberg commented on GitHub (Jul 13, 2024):
Nope, most of variables from
.envincluded indocker-compose.yml, and so all worksMy
docker-compose.ymllooks like this:File was taken from here
@phanan commented on GitHub (Jul 13, 2024):
But if
APP_KEYis already in the environment variables, how come Koel doesn't recognize it? If we look atapp/Console/Commands/InitCommand.php:128:I'd assume that
$keyshouldn't be empty here.@Mark-Shternberg commented on GitHub (Jul 14, 2024):
I add
APP_KEYindocker-compose.ymlyesterday, before that it was not there, and therefore it changed every rerunkoel:initNow when I add it to
docker-compose.ymlKoel recognize it and use as expected, but it doesn't help with errorNew note: I noticed that an error appears after run
php artisan koel:init --no-assets, not after recreating docker container, here my steps to reproduce:@phanan commented on GitHub (Jul 14, 2024):
This is getting more and more curious. As you can see in the screenshot,
koel:initdidn't even change the app key, indicated by "Using app key: …" which is how the code's supposed to work.This is my output, also on Docker:
@phanan commented on GitHub (Jul 14, 2024):
I think the problem does not come from the fact that
APP_KEYwas regenerated (because it wasn't). To validate this hunch, can you add this line afterapp/Services/LicenseService.php:26and go through license activation and status checking again? If the value remains unchanged, something with your setup might be causing the license encryption and storing to go wrong.
@phanan commented on GitHub (Jul 14, 2024):
@Mark-Shternberg I deleted your comment as it contained your license key.
@Mark-Shternberg commented on GitHub (Jul 14, 2024):
The hashes are absolutely the same in the logs both during activation and during verification
@phanan commented on GitHub (Jul 14, 2024):
Great, thanks! Then the storing must have gone wrong somehow. Can you try replacing
app/Casts/EncryptedValueCast.phpwith this? (basically adding two lines of log but I don't want to confuse you):The values logged should be exactly the same.
@Mark-Shternberg commented on GitHub (Jul 14, 2024):
nope, they are different:
@phanan commented on GitHub (Jul 14, 2024):
Very interesting. How many rows do you have in the
licensestable?Edit: Though, actually that wouldn't explain why decryption of the second value
eyJpdiI6IjlMd25JNVg…fails.@Mark-Shternberg commented on GitHub (Jul 14, 2024):
I have 2 rows with id 1 and id 3, one created 2024-07-12 11:51:13, second 2024-07-14 11:42:35
@Mark-Shternberg commented on GitHub (Jul 14, 2024):
id 1 has key like "Encrypted" from log
id 3 has key like "Trying to decrypt" from log
@phanan commented on GitHub (Jul 14, 2024):
That's what I thought! So you somehow have a leftover key that was likely encrypted with an old
APP_KEY, and Koel's been checking against this key instead of the new one (likely because this key somehow has a newer id). I believe emptying the table will solve your problem, but I'll see how to fix the issue from Koel's side as well.@Mark-Shternberg commented on GitHub (Jul 14, 2024):
Yep, problem was here. I deleted rows, reactivate license and now all works great! Thanks for help, that was interesting :D
@phanan commented on GitHub (Jul 14, 2024):
Thank you! Was interesting to me as well.