Hi,
I have a page on my back end with a pretty graphic, depending on the user that has logged in. In Dropsource I display this as a WebView, however when I display the url, it shows the error “missing token” as expected, as the WebView was never provided the token for the page to authenticate.
How do I send the accessToken to the WebView request so that the WebView displays content specific to the user that has logged in to the app?
Thanks in advance for your help.
Hi @Theo, so webviews are limited in the data that can be passed from your app and within them to webpages by default. The think you might do is handle the login process outside the webview so that you receive a token back through an API request’s response. Then you could, although it’s not the most secure means, you could add the token to the end of the url for processing by your backend for authentication to make this work.
Hi @wade, thank you for getting back to me. That is what I have done, and tried to send the accessToken as a url query string (i.e. ?access_token= ). I was just wondering if there was a way to do it that the help files did not cover.
That being said, what is User Agent? I read that it help update the headers, but honestly, it wasn’t very clear in the Android dev documentation. Is there any way I can change the headers that are being sent in the url string?
I know I’m grasping at straws here…
Thanks in advance for your help.
@Theo, As of now you’re limited to putting together a url to pass information. We don’t currently support anything within Dropsource to more depth. I wish I had more to pass on that but if it’s not being passed within the url, then it’s not able to be passed through a webview unless your webapp from within the webview is setup to pass more information manually.
Hi @wade. Thank you. That makes sense. I’ve got it to work with passing it as part of the url, but waiting in case you guys to possibly add that feature.
Thanks again for your help and keep up the great work!
Hi @Theo I’m glad you could get it to work. I don’t think we’ll be adding that header adjustment feature but if this style can suffice, that will be great.
Hi @wade. It will work for now. The bummer is the security as the token is being passed openly. At least I have an SSL connection which makes things better. Works for now so I’m happy.
Thanks again.
Yes this is not ideal. It will remain a limitation when working with webviews in a secure manner. If you go truly native however, you can add tokens inside the api request away from the url path but if you stick with a webview, it will continue to be exposed unfortunately.