Update Issue from 3.4.1 to 3.4.2 about dockerfiles HOT 48 CLOSED

From the error the problem is likely related to your value for APP_KEY in the .env file

from dockerfiles.

Wow adding an APP_KEY to the .env file that is exactly 32 characters long, fixed the issue. Thank you

from dockerfiles.

@hillelcoren I'll create a new PR to revert my breaking PR - after the fix it can be reapplied.

The config file app.php currently looks like this:

    'key' => env('APP_KEY', 'SomeRandomStringSomeRandomString'),
    'cipher' => env('APP_CIPHER', 'AES-256-CBC'),

https://github.com/invoiceninja/invoiceninja/blob/master/config/app.php#L85-L87

I think after the fix it should look like this:

    'key' => env('APP_KEY'),
    'cipher' => 'AES-256-CBC',

https://github.com/laravel/laravel/blob/5.2/config/app.php#L94-L96

Also no APP_KEY should be hardcoded anywhere in the Dockerfile

from dockerfiles.

Are there any details about the error in storage/logs/laravel-error.log

from dockerfiles.

the log shows: [2017-07-17 10:33:33] production.ERROR: RuntimeException [0] : /var/www/app/bootstrap/cache/compiled.php [Line 7843] => No supported encrypter found. The cipher and / or key length are invalid. {"context":"PHP","user_id":0,"account_id":0,"user_name":"","method":"GET","url":"https://domain","previous":"https://domian","user_agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36","ip":"ip","count":2,"is_console":"no","is_api":"no","db_server":"mysql"} []

from dockerfiles.

There is no APP_KEY value in my .env I try to find out if there was any

from dockerfiles.

This file was not changed since months...

from dockerfiles.

Is there a value for APP_CIPHER

from dockerfiles.

There is no value for APP_CIPHER in the .env file

from dockerfiles.

Maybe this will help...

invoiceninja/invoiceninja#1573

from dockerfiles.

hm works only for the login page. when i try to login the same happens

from dockerfiles.

Try using SomeRandomStringSomeRandomString as the APP_KEY

Note: this is insecure, the APP_KEY should be a random value.

from dockerfiles.

How did this ever work without a APP_KEY?

from dockerfiles.

@SandroRaV are you using the latest or 3.4.2 docker tag?

from dockerfiles.

@hillelcoren that did not work with the somerandomstrin
@arubacao I am not suer why it did work but it did. Where do I see the docker tag?

from dockerfiles.

depending on which start command you use.
However your command or docker-compose.yml somewhere includes the image name:
invoiceninja/invoiceninja
It is either

1. invoiceninja/invoiceninja:3.4.2
2. invoiceninja/invoiceninja:latest or invoiceninja/invoiceninja (defaults to latest)

from dockerfiles.

it is only invoiceninja/invoiceninja so it defaults to latest. any way to get around this issue?

from dockerfiles.

Have you updated the app before or is this the first time?

from dockerfiles.

Yes, did 5-6 updates with the same procedure and no changes in the .env file and all of them did work

from dockerfiles.

Try adding to your .env file:

APP_KEY=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
APP_CIPHER=AES-256-CBC

and then restart the docker containers

from dockerfiles.

added but still the same issue. I can login but the error stays the same

from dockerfiles.

Still with the same issue No supported encrypter found. The cipher and / or key length are invalid. ?
Also try:

1. Flush cache
2. Kill the compiled files

At the very least you will get a more detailed call stack.

edit:
or be sure to have already added the APP_KEY & APP_CIPHER to the .env; completely remove the docker image & container (only invoiceninja); re-pull and restart invoiceninja.

The only error you should be getting is a invalid password since you "changed" your APP_KEY

from dockerfiles.

looks like the error has changed:

[2017-07-17 19:50:08] production.ERROR: Illuminate\Contracts\Encryption\DecryptException [0] : /var/www/app/bootstrap/cache/compiled.php [Line 13310] => The MAC is invalid. {"context":"PHP","user_id":1,"account_id":1,"user_name":"user ,"method":"POST","url":"https://domain/login","previous":"https://domain/login","user_agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Firefox/54.0","ip":"172.18.0.1","count":1,"is_console":"no","is_api":"no","db_server":"mysql"} []

what do you mean by flush cash / kill the comiled files?

from dockerfiles.

go into the docker image (something like docker exec -it invoiceninja_whatsoever_1 bashand execute:

php artisan clear-compiled
php artisan cache:clear
php artisan config:clear
php artisan view:clear

This removes all cached files

from dockerfiles.

okay that works for one login when I do this and then restart the container I am able to log in once. When I try to do this again I see the same error

from dockerfiles.

Try commenting out these 6 lines of code:

https://github.com/invoiceninja/invoiceninja/blob/master/app/Listeners/HandleUserLoggedIn.php#L67

from dockerfiles.

okay that works until I go for the Online Payment section in settings... When I klick them the same error appears

from dockerfiles.

Thanks, that's helpful to know. It seems likely the APP_KEY value has changed. If it wasn't set initially it should be using the default value. I'm not sure why upgrading caused this problem.

Without the original APP_KEY value the app won't be able to decode the payment gateway settings. If you don't have any billing tokens stored the simplest fix would be to manually mark the data in account_gateways table as archived/deleted and then re-add the payment gateway.

from dockerfiles.

@hillelcoren i guess this issue comes from my PR #52
The base image is now php7.1 without mcrypt instead of php7.0 with mcrypt.
Mcrypt was blocking the php upgrade. Laravel doesn't require mcrypt anymore and

Relying on this function is highly discouraged. link

I tested everything with my own real data and it worked.
However, I was a bit confused that an APP_KEY was hardcoded into the Dockerfile, but since the APP_KEY was under 32 chars - and therefore shouldn't work - it didn't bother me too much.
But now i'm not so sure anymore as @SandroRaV stated that he never used a APP_KEY.

I didn't have time to test it, but my bestguess to replicate the issue:

1. Pull a docker image tagged > 3.4.2 (before my PR)
2. Do NOT use a .env file with an APP_KEY and APP_CIPHER
3. Create a user (so something is encrypted)
4. Now pull the docker image tagged latest (after my PR)
5. error should occur

So I guess this causes problems for people NOT using a proper APP_KEY and using the hardcoded one in the Dockerfile. Breaking an invoiceninja instance is of course a big issue, however using the hardcoded APP_KEY is also extremely risky.

I don't know about a good solution for this. Maybe some sort of re-encrypting the data with a proper APP_KEY

EDIT:

But i'm not 100% sure because @SandroRaV was able to login with a different APP_KEY 😕

from dockerfiles.

I do have tokens in the payment gateway part so I am interested into finding another way then deleting them if possible

from dockerfiles.

@SandroRaV a quickfix would be to use a tagged version instead of the latest. Also remove the newly added APP_KEY and APP_CIPHER

from dockerfiles.

can I use 3.4.1?

from dockerfiles.

should work up to 3.4.2

from dockerfiles.

it looks good with version 3.4.1 now.

from dockerfiles.

I agree using the default is a bad idea but we also can't simply remove it. Please add back the default value so it continues to work for existing users. In our next release we'll create an Artisan command to change the APP_KEY and warn if the app is setup with a default value.

FYI... my understanding is the APP_KEY is used to encrypt session data but not for checking the password on login. The app uses the APP_KEY to encrypt the payment gateway and banking credentials. We check the payment gateway settings on login which was causing the error.

from dockerfiles.

so will the next version fix this for me?

from dockerfiles.

You're currently using a default value for the APP_KEY, in the next version we'll try to make it possible to change it, this will improve the app's security.

@arubacao Removing mcrypt may be a problem as well.
@lalop What do you think?

from dockerfiles.

Sounds good, thanks!

from dockerfiles.

@SandroRaV The app should work if you use the tag 3.4.2, latest is more advanced. Generally it's better to tag you image and manually update the tag version when you want to make an update to avoid unexpected update on side container, I had some issue updating mysql like taht ;)

@arubacao why don't just add back ENV APP_CIPHER rijndael-128 ?

from dockerfiles.

If @hillelcoren writes an upgrade command, i'd recommend the default AES-256-CBC
It seems like the only 2 supported ciphers are AES-256-CBC & AES-128-CBC since Laravel 5.1 link.

RuntimeException: The only supported ciphers are AES-128-CBC and AES-256-CBC with the correct key lengths.

from dockerfiles.

This sounds somewhat stupid but maybe mcrypt rijndael-128 == openssl AES-256-CBC (?)
So the only problem would be the key length

creates a cipher text compatible with AES (Rijndael block size = 128) link

from dockerfiles.

So we have no choice, you will keep php 7.0 for now

from dockerfiles.

I've checked in two changes:

• When logging in the app will check that APP_KEY isn't set to a default value
• Added an Artisan command to update the key and re-encrypt the data

These changes will be included with v3.6, I think it'd be best to wait until v3.7 to re-apply these changes.

from dockerfiles.

sounds good to me 👍

from dockerfiles.

@hillelcoren I just came across this repository: https://github.com/laravel/legacy-encrypter

This encryption package provides support for the legacy Mcrypt encrypter used by Laravel 5.0 through 5.2. It is primarily intended to be used to migrate your data to the new OpenSSL based encrypter used in 5.1 through the latest release of Laravel.

Maybe this helps

from dockerfiles.

Hello @hillelcoren
Your command can't work in a docker environment since the container is in readonly te application can't write to the .env file.
Instead the environment variable are real environment variable.
So for now the command output an error

  [ErrorException]                                                                        
  file_get_contents(/var/www/app/.env): failed to open stream: No such file or directory 

Maybe the command could simply output the new key in this case and let the user update is variable ?

from dockerfiles.

Thanks for letting me know, I'll take a look

from dockerfiles.

FYI... I've checked in a fix for this.

from dockerfiles.