Header authentication

[albinmedoc]

No description provided.

[cmintey]

Can you also add a global flag to completely disable this functionality? HEADER_AUTH_ENABLED and default it to false?

I don't have too much knowledge of header auth, but I do know that it can be pretty dangerous if the upstream proxy is not configured properly. Obviously that is not Wishlist's job to know about that or enforce it, but I think there should be a disclaimer in the docs about that. Maybe something like

Warning

When header authentication is enabled, Wishlist makes no assumptions about the validity of the headers. It is up to you to have your proxy properly configured. An improperly configured proxy could allow anyone to gain access to the application by forging the headers.

[cmintey]

Couple other things to consider

• How will this play with the "setup wizard" flow
• Add this to the signup flow for users who receive an invite token/url
• Should we block users who were created via headers from changing or resetting their password (change password flow won't work because the password is blank)

[albinmedoc]

Couple other things to consider

• How will this play with the "setup wizard" flow
• Add this to the signup flow for users who receive an invite token/url
• Should we block users who were created via headers from changing or resetting their password (change password flow won't work because the password is blank)

• I have now made it so that the first user goes through the setup wizard regardless of whether proxy auth is enabled and values are sent in headers. If you want the first user to work with proxy auth, you need to set the username to the same as what will be sent with the headers.
• Should this automatically create the user and add them to the group that the invitation pertains to?
• I can make it so this is blocked in the UI. It doesn't really matter if the user changes the password or not, but it might be good to hide it to avoid showing unnecessary things.

[cmintey]

Couple other things to consider

• How will this play with the "setup wizard" flow
• Add this to the signup flow for users who receive an invite token/url
• Should we block users who were created via headers from changing or resetting their password (change password flow won't work because the password is blank)

* I have now made it so that the first user goes through the setup wizard regardless of whether proxy auth is enabled and values are sent in headers. If you want the first user to work with proxy auth, you need to set the username to the same as what will be sent with the headers.

* Should this automatically create the user and add them to the group that the invitation pertains to?

* I can make it so this is blocked in the UI. It doesn't really matter if the user changes the password or not, but it might be good to hide it to avoid showing unnecessary things.

• Sounds good
• I think yea, create the user automatically and assign them to the group in the invite. Users can also be invited without a group, so use the default group (if set)
• I think just make the password reset fields disabled on the user account page. If a user goes through the password reset flow and doesn't have a password, then we can allow that, I suppose

[albinmedoc]

@cmintey This is now ready for a review.

I have implemented a function for creating a user, just so don't have duplicated code everywhere.

[cmintey]

Looks good. Just a suggestion to add some logs when the required headers are missing. Can just use console.log since I haven't set up any real logging yet

[cmintey]

Maybe add a log message here that the header variables are missing

[albinmedoc]

Yes, I will fix!

[cmintey]

Maybe add a log message here as well that the required headers are missing from the request

[albinmedoc]

Yes, I will fix!

[albinmedoc]

I have added logging @cmintey