Safari ignores hashtags in hyperlinked URL
agates4 opened this issue · comments
http://i.imgur.com/UTWxiEJ.gifv
In gif, user is directed to authentication with MLH
Then redirected to our server with the access token
But because of the Hashtag, the data is deleted and redirected to server without data
Solution suggestion: convert to using question marks instead of hashtags :)
Hi Aron,
It's actually intentional (and part of the OAuth protocol) for the access_token to be passed through as a # / hashtag parameter because that way it isn't visible by the server and the server logs.
If you use the MyMLH Authorization Code Flow you'll be able to receive everything as a ? / question mark parameter as that's a far more securer and better recommended flow for MyMLH applications.
With that being said, I wasn't aware that safari does not have full support for hashtags. We'll debate this internally and see if there's any solutions we can roll out. Hope that helps!
Thanks Bilawal! That helps, we're currently looking into solutions on our side.
Thanks for replying so quickly!
You're welcome!
Hi Bilawal, I am also working on the project with the issue.
I will setup the application to use the Authorization Code Flow, but I initially did not as the documentation mentions
You wouldn't want to use this on your client side application because your application's secret token would be exposed to the world.
Our application is a client application and users will only be accessing information about their profile. Would it still be acceptable / safe to use that flow? I was under the impression that this flow should only be used for those that need access to all registered users (Organizers and etc.). I am confident that this flow would resolve the problem, but I do not want to sacrifice security.
Update:
In addition, there is currently no way to 100% securely store an app secret on android, as the secret (or some method to access the secret, i.e. through a server) would have to be stored somewhere in the source code, which is possible to be decompiled due to it being java. Therefore, it would be unsafe to use the Authorization Code Flow as the client secret could be accessed and any user would then be able to authenticate and access all user data.
It would be most ideal from what I have currently seen to continue to use the Implicit Flow as a hacker would only be able to access a single user's data, rather than all user data. I would appreciate any input you have on this.
Hi csinko,
You shouldn't use the Authorization Code Flow on a client-side only application. That's why the Implicit Flow exists, because in the ideal world, we'd want everyone to use Authorization Code Flow.
Realistically, the best option you have right now is to create a very lightweight backend that contains these credentials and makes requests to MyMLH. Then your mobile application can connect to your backend which will connect to MyMLH. This would also be great for a client side application as it could connect to a backend. It's not ideal at all, and we'll be investigating ways to make this easier, but it's a viable option for now.
And we'll be investigating the following:
- Workaround for storing client ID and secret in a mobile app that can be decompiled
- Implicit Grant Flow with support for browsers with little hashtag support in URLs
Hope this makes things clearer. Cheers!
bih,
I have read more into the Safari issue and was able to get a working solution without much change.
The issue is occurring due to the fact that I have our webserver doing a 301 forward from http traffic to https. A common way to have it setup, and something that you set and forget, as all traffic ends up going to https as desired. Safari was dropping the # variables during the 301 redirect, while other browsers do not.
The solution was to simply update our callback URL to include "https" so that the 301 redirect process is not needed, and it is working great now!
Ah okay, glad to hear that you were able to fix it. Let me know if you have any other questions. 👍