mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-05 00:29:48 +03:00
HTTPS connection downgraded to HTTP after social login success #1260
Reference in New Issue
Block a user
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 @mariuskiessling on GitHub (Jul 15, 2019).
After a user successfully authenticated using the social AzureAD login, BookStack receives Azure's login redirect (via HTTPS) but drop to HTTP when redirecting to the homepage. I could not test it using a different authentication provider but this issue should not be limited to AzureAD logins.
This issue occurs due to a faulty location header in BookStack's callback handler response.
8fcb0e6820/app/Auth/Access/SocialAuthService.php (L112)The app URL is set to HTTPS.
Steps To Reproduce
Expected behavior
After the callback by AzureAD is processed, don't redirect the user to the insecure HTTP site.
Screenshots
Configuration
@ghost commented on GitHub (Jul 15, 2019):
I am observing the same issue and would be interested in seeing this fixed. Especially for end users or network environments with high-security awareness, this might cause failures or losing trust to BookStack.
@ssddanbrown commented on GitHub (Jul 15, 2019):
Thanks for the clear information @mariuskiessling.
This is likely due to BookStack being behind a proxy, in which case BookStack is actually receiving the original request via HTTP which is remembered as a location for this redirect action.
It's likely related to #1459 which is due to be looked at for the next release therefore I'll also include this to be looked at.
@mariuskiessling commented on GitHub (Jul 15, 2019):
@ssddanbrown That’s a really good point. We are running BookStack behind an envoy proxy as part of a service mesh. The encryption of traffic is fully transparent to the service thus every connection looks like HTTP to BookStack.
Would it make sense to split the indented path and only save the relative path to the requested ressource? If needed the application’s domain could be prefixed. This would also only require minor modifications.
@ssddanbrown commented on GitHub (Jul 15, 2019):
@mariuskiessling Yeah, That makes sense and is the general plan. It may be a little tricky though as you never know how that URL will be transformed by the time it reaches BookStack, Some people may have BookStack on a deep nested path (
https://example.com/my/lovely/cat/wiki) which would need be be handled properly.Since originally writing much of the original URL logic I've gotten a better grasp of the Laravel framework and I can now see a cleaner way to handle URLs in BookStack so I'll probably do this as part of a larger refactor for the next release.
@ssddanbrown commented on GitHub (Aug 4, 2019):
Significant changes have been made to URL generation in
4b0c4e621awhich should now fix this.These changes will be in the next release, v0.27. I will close this request in the meantime. If you continue to experience issues after that version is released please open a new issue referencing this one.
@mariuskiessling commented on GitHub (Aug 4, 2019):
@ssddanbrown Thank for addressing this issue so quickly!