I'm trying to utilize the localStorage in a chrome browser to implement a login feature using Angular. I'm using this resource as reference: http://jasonwatmore.com/post/2016/08/16/angular-2-jwt-authentication-example-tutorial.
The problem is when I save a variable in localStorage using
localStorage.setItem('currentUser', JSON.stringify({ username: username, token: token }));
the app passes authentication and redirects to a welcome screen. However, in the chrome dev tools->application->Local Storage->http://localhost the variable appears and then disappears in about a second. I verify that it is no longer saved becuase trying to refresh redirects me back to the login page.
Why would the localStorage be clearing my data when nowhere in my code do I call localStorage.clear?
I even downloaded Jason Watmore's github project from the link above and when running that application I get the same problem.
To reproduce:
run app in chrome
login using the given credentials
view localstorage from chrome dev tools
refresh page and it will ask to login again
EDIT :
It appears to be working now and I have no idea why. What I did was restart my computer, and consequently the my servers as well and now the variable remains in localStorage as expected. If anyone could shed some light on what was going on under the hood I would be grateful.
Related
I have an app running and this seems to be fine unless a specific process happens in mobile. When leaving the app on the dashboard for some time and going back after the session time has laps. I log back in to the app then clicking on the link in my plugin that is using the banno-plugin-framework-bridge deeplink the page is asking for authentication even though the app already asked for login for the app. I am not saving anything in session just authenticating. The only way I have found to resolve is to leave the dashboard screen and come back and click the link.
This does not happen in desktop so this has been harder to solve. I tried adding logs but because it is redirecting to the login for authentication I am not able to render a reason for it to need to authenticate again. When I tried in desktop to see if there was a session that I can target I am not seeing anything come back with javascript call "document.cookie"
So we switched a website from example.com to www.example.com (and implemented a forward to www.example.com). I believe I still have Google Chrome site data which causes problems (Shopware 6 trying to load data via API from example.com - without www) on example.com and this somehow influences www.example.com.
I already cleared the site data for www.example.com (Chrome dev tools -> Application -> Clear site data)
But how can I do this for example.com which directly forwards me to www.example.com ? I could not find an option in the dev tools to switch the domain I am looking at.
Chrome has it`s own DNS-Cache. I had that issue a lot and started to use CURL in the terminal instead when checking whether a redirect is working or not.
But Afaik you can also clear that cache:
Open a new tab.
Type the url in the search box: chrome://net-internals/#dns
Hit the “Clear host cache” button. And you are done as DNS is flushed out.
Open another tab and type URL: chrome://net-internals/#sockets
Click on the “Flush socket pools” button. Close the Google chrome
tab.
source: https://www.cyberciti.biz/faq/google-chrome-clear-or-flush-the-dns-cache/
At least that worked in some cases for me.
Can you verify that it is a browser problem and not a shopware / server problem? Did you check that the URLs in the html for loading the fonts is the correct URL, or is the old URL still used in the html?
If thats the case you should ensure that you also updated the URL in the sales channel domain settings and also update the APP_URL environment variable. After that clear the cache.
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.
We changed our production application name and description by forge.autodesk.com/myapps. But on authorization page we still see the old one.
Can we force to refresh it somehow?
Clearing browser cache didn't help. We've been wainting for 2 days but it still doesn't work.
Just got confirmation from Engineering that they've pushed the fix to production.
If you create a new app, the authorization page should show the name of the app properly. If you still want to use any impacted app, please edit and save the app.
I am currently trying to port a Chrome extension to Firefox.
The Chrome extension has a "Login" page, which is opened in a new tab as an HTML document. The HTML document is stored in the local directory with other extension files. The user inputs a URL which should represent a server running our application, where the user will be asked to login. After a successful login, the user is redirected back to the options.html page, which is updated to show the user's preferences.
I would like to duplicate this in the Firefox extension, i.e. I would love to avoid writing anything in XUL to build an options page.
I tried opening a new tab with my HTML page like this:
var url = "chrome://myextension/content/options.html";
var win = Components.classes['#mozilla.org/appshell/window-mediator;1']
.getService(Components.interfaces.nsIWindowMediator)
.getMostRecentWindow('navigator:browser');
win.gBrowser.selectedTab = win.gBrowser.addTab(url);
But I don't like this for a few reasons: 1) The navbar in the new tab displays the "chrome:// ..." URL, and 2) it breaks the authentication process. The authentication is done using an OAuth type system, and the current URL is passed into the API so that the user can be redirected back upon successful authentication. The authentication fails with "chrome://" as part of the URL.
Just out of curiosity, I tried hardcoding the URL like this:
http://myextension/content/options.html
And the user is actually successfully authenticated, but then the redirect obviously fails afterward.
The Chrome extension seems to work with no problems or weird hacks. From what I can tell, opening it works like this:
chrome.tabs.create({"url":chrome.extension.getURL("options.html"), "selected":true});
And referencing the URL of the tab later so we can be redirected back to it just works like this:
var options_url = chrome.extension.getURL('options.html');
So, I'm wondering: what is the best way to open a local HTML document in a new tab with a Firefox extension, without using the "chrome://" "protocol"? Is there a similar way to how it can be done with Google Chrome extensions?
UPDATE 23/5/12
So this article says that chrome:// URLs are not accessible from the web, only locally.
http://adblockplus.org/blog/web-pages-accessing-chrome-is-forbidden
I think this could be the reason why my authentication was failing. I'm definitely looking for a way for my extension to display a local HTML file in a window or tab without using chrome://.
UPDATE 07/6/12
Here is my (hopefully temporary) solution:
The user enters the URL of the server running our application. He/she is redirected to the application login page, but instead of passing "chrome://myextension/content/options.html" as the URL to be redirected back to after authentication, I pass a phony URL, i.e. "http://myextension/thisis/madeup.html".
In my extension's overlay.js, I set up an HTTP request listener which listens for the phony URL being requested. When a GET happens for the phony URL, I cancel the request, and open the real, locally stored page at "chrome://myextension/content/options.html".
See the following references:
https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIObserver
https://developer.mozilla.org/en/XUL_School/Intercepting_Page_Loads#HTTP_Observers
If you're trying to do this redirect for an OAuth call you should try using OAuthorizer from Mozilla instead of doing the redirect work yourself. Hope that helps!