Issue: appears to be that banno framework is "remembering" the urls. This is happening in a mobile browser when the user does not close the tab or browser. When the user opens the page, banno is remembering the url from last time and trying to load the same url.
What needs to happen is that banno needs to fully reload the page so that we can go retrieve a new url and log the user in again.
Could it be how they treat plugins when a browser is left open. A url that is loaded is not good forever.
Odds are good that the situation you're encountering is described in https://stackoverflow.com/a/71267143/6680761
Essential info from that link is:
Part of keeping state of the page is keeping authentication data. The OAuth flow used to initially authenticate the user is not intended to be used on every page refresh. It's expected that the embedded web application will keep its own authentication state. How this is done is usually very specific to the language and platform used for the embedded web application. However all strategies almost exclusively use a cookie which is destroyed when the application closes.
The Oauth callback URL with an authentication code should be redirected away from once the code is exchanged for an access token. From that point forward your app should be using its own authentication mechanism.
Related
I am new to computer networks and have a simple question. Assuming that we want to visit a website www.aaa.com, and the website includes a picture . When we try to access aaa.com, who launched the resource request on bbb.com, the aaa.com server or the user-side browser? I have two thoughts:
User first downloaded the html file of aaa.com and the browser executed the code in it, so the user browser finishes resource request.
The aaa.com launches the request, and prepares all the sources, then gives back to user browser.
Which idea is right?
Unless a visitor is using a proxy which redirects all traffic through website aaa.com then what bbb.com site will see is a request made from the users browser.
Your HTML file essentially acts as a pointer to all the resources needed by the website; browser then fetches all the resources accordingly. This is usually called a Cross-Origin call.
You can open up your Developer Tools in your browser to see the calls under the Network tab.
If you want to delve deeper into the subject take a look at CORS on MDN.
I have read about SPA (single page application) and learned that biggest advantage of those is that save network traffic because SPA downloads all (at least most of them) application resources when loading the page.
But I am not clear on this - suppose in my index.jsp I have specified all my resources and downloaded when loading index.jsp. Now my application navigation starts from index.jsp, so for navigation I submit my form and which has action="user.jsp"
Now, since I have action="user.jsp" so on submitting the form my web browser will send a request to server to get user.jsp. Please correct me if I am wrong. Or will be taken from HTTP cache. But lets say through some Apache setting (I have read somewhere that it is possible but don't know how to do it) I have disabled the HTTP caching of web page then user.jsp will be downloaded from server.
Much appreciated if somebody can throw good insight on it. Basically I am confused with the fact that action="user.jsp" will lead a call to server and HTTP/browser can cache web pages.
P.S.: I accidentaly posted my question here as a guest user but now unable to remove that, so if you have moderation authorities then please get that question remove to avoid duplication.
I use gifjs to generate a lot of gifs from png/jpg files once user logins success. At same time, I want to change the location.url to direct user to my website main page. But the problem is that the web worker task stopped once the url is changed. So how to execute web worker task continuously even though the location url is redirect?
If the browser does a load of a new page, the short answer is that workers will be terminated. Definitely dedicated workers, and according to Do Shared Web Workers persist across a single page reload, link navigation shared workers (that aren't being used by other windows/tabs) will be too.
But...
If you didn't use any full page loads, and made the entire site use Javascript for navigation / posting of forms, and use the HTML history API to change the URL, then the worker will survive as the user logs in and navigates the site. The worker will only be terminated when they leave the site, or force a reload in the browser.
Depending on the current setup of your site, this might mean considerable change of both the browser and server architecture, the details of which I suspect are beyond the scope of this question.
Firstly any news on the V2 SDKs for iOS and Android?
The normal flow is:
In app: click authorize button.
browser opens box.com/api/oauth2/authorize?....
User inputs their details.
User is taken to an allow/deny page.
User taps allow or deny.
User is taken back to app via the redirect_uri scheme.
My problem is once the user has put their details (3) in once and arrived at the allow/deny page, any future attempts to authorize full on skip the allow/deny page and go straight to the box home page without ever calling the redirect_uri along with the auth codes.
This can be 'fixed' if the user clears their browsing history/cookies before trying again, which is a long way from ideal. Any ideas?
For a potential short term fix until the v2 sdk is released, a web view can be used which will give you full control over things like the cache (we are using one in the sdk).
I'm adding Box support to an iPad app. I tried the official SDK and I don't want to use it for the following reasons:
Login page is too wide for a modal controller with UIModalPresentationFormSheet style on iPad. The SDK hosts UIWebView which loads content of https://m.box.net/api/1.0/auth/, which perhaps returns HTML with min width set to 768px (although I didn't check the HTML, speculating here).
HTML in login page doesn't show Google Apps authentication option. The full desktop version of the page does.
Because the login page is hosted in UIWebView the user cannot be sure that he's supplying the credentials to Box, and not to an app author.
I don't need the whole SDK functionality, just authentication, folder/file listing and content download. Since my app also uses other cloud storage providers I'd prefer to provide uniform file browsing experience.
Here's what I'm going to do:
Add a custom URL scheme for my app, let's say "myapp".
In Box's Application settings for my app set Redirect URL to myapp://RedirFromBoxAuth.
When the user chooses to browse Box from inside my app, I'm going to:
Get a ticket by calling GET https://www.box.com/api/1.0/rest?action=get_ticket&api_key={API_KEY}
Extract the ticket, then call openUrl with https://www.box.com/api/1.0/auth/{TICKET} This will open Safari and let the user enter his credentials. This is the full, desktop version of the login page.
On successful login Box's server will tell Safari to redirect to myapp://RedirFromBoxAuth?ticket={TICKET}&auth_token={TOKEN}, which in turn will tell iOS to yield control to my app.
My app receives handleOpenURL notification and I can extract the authentication token and use REST API from now on.
Please comment, is it a good plan? I created a quick prototype and it seems to work, but maybe I'm missing something?
Box team, could you please tell us will an app using this authentication model be eligible for inclusion in OneCloud?
This seems like a good strategy and will probably make for a better UX/easier implementation than the normal redirect. Please let us know if you run into any weird edge cases by implementing it this way.