secure_satis: true does not work with BasicAuth

[NeoBlack]

I have set secure_satis: true, the packages.json is now protected by a BasicAuth but entering the credentials does not enable the access to the files.
not in browser and also not by composer

[tyler-sommer]

If you change the username/password to something extremely basic such as admin and password, does it work? I'm wondering if there is a problem when parsing the yaml configuration. Additionally, you may need to clear your cache directory.

You could also do the classic die() debugging, for example in: https://github.com/terramar-labs/packages/blob/master/src/Application.php#L56 throw a die($security['username']); in there to verify that the configuration is being read correctly.

[NeoBlack]

Config is correct, $security contains the username and password from the config.yml.
after entering the data, the dialog comes back and ask again for the credentials.
I will try to setup the the tool on my local machine today, it's better for debugging.

[strausmann]

Hello Tyler, could you until the implementation of the feature (#77) add a second user?
This user can only access satis. I would like to secure satis and allow access for certain users. But would like to avoid that you log into the admin.

For me, the Basic Auth currently does not work as expected.

Many thanks,
Regards,

Bjoern

[strausmann]

Hello Tyler,

i think I have found the mistake. The password_hash() function use with the PASSWORD_DEFAULT algo a bcrypt-Algorithmus Password. But in the config.yml File is the passwort in plain-text saved.

Regards,
Bjoern

[NeoBlack]

good catch @strausmann so the fix is to use an encrypted password hash (which the best idea) but will the login still works? will check it in the evening.

[NeoBlack]

so, on my local system the BasicAuth for /packages.json work with a plaintext password., on my web server it does not work. on both system an encrypted password does not work.

[tyler-sommer]

The password is hashed during application boot, though I agree the password should be hashed in the config file itself. This would be considered a BC break, however, so I want to avoid it if possible on the 3.x line.

The password entered during authentication is also hashed before comparison, so you should enter the plaintext password when authenticating.

I admit, though, I'm at a loss at what could be causing your issue, especially given it working locally. What does your setup look like, in both environments-- how are they different? Could it be a webserver configuration causing the problem?

[NeoBlack]

It must not be a breaking change, an encrypted password (and the algorithm) can be detected by the prefix. example:

plain: password
brcypt: $2a$04$ntozz44SYhGgHBUEMSvYKOvWmVqMVC9v.PVfeDuEYzr7L.BL7r7e2

check the possible prefixes:
https://en.wikipedia.org/wiki/Bcrypt#Versioning_History

sure, the local setup is different from the server, but the server "normal" debian webserver. I will attach a PHPInfo output

[tyler-sommer]

Excellent suggestion, @NeoBlack, I think that's a great way forward. There is already a utility in vendor/bin/hashpass that is shipped with nice-security. This utility could be used during a Composer post-install hook for the user.

I've opened #91 to track that feature.

However, this doesn't address your issues with authenticating. Is that still an issue?

[NeoBlack]

yes it is still an issue, I had not the time yet to debug it on the server or have a deeper look into the code. Will try to check it the next days.