I have a system made on vueJs. When I do login it saves accessToken and refresh token in browser cookies. It works fine in all computer and network. But specific in one PC it saves only refresh token and avoiding to save accessToken. I have no idea what can I do.
I suspect that this is a browser-settings thing. If your user decides not to save cookies at all, the browser will not save cookies. You can check the settings in that browser, or try a different browser on that machine.
What you usually need to check is not different pc's, but different browsers on one pc.
If you want to be thorough, try safari on mac & firefox and chrome on windows.
Depending on your audience, you may also still need to check internet explorer, but this is getting less and less common.
Related
I maintain an application written in C++Builder 2009. Part of it involves using a TWebBrowser control (based on Internet Explorer) to send users to a Google login page in order to obtain an OAuth key. This has worked well for a while, but now Google, bless their hearts, has implemented some kind of security upgrade, and now my users get to a page that says "Couldn't sign you in, this browser or app may not be secure". FYI, I am already setting a Registry key that is supposed to make IE run in version 11 emulation mode.
I do have a couple of workarounds: If the user runs IE first in admin mode, signs on, leaves it up while running my application, we don't get the problem. Second, I can start up the default browser - Chrome, IE, whatever - and send them to the URL for OAuth, then it avoids the error message.
The problem with this solution is that without being able to hook into TWebBrowser events, I don't have any way to automatically retrieve the OAuth key - it is necessary for the user to cut/paste it into my application. I'd like to avoid these clunky solutions.
I should also mention, this problem occurs only for certain Gmail accounts. I have no idea what the difference is between accounts that work and don't work. Any ideas on that?
So, is there any way to configure IE or TWebBrowser so this security issue is bypassed? Or, if I was to update to a modern version of C++Builder and use TWebBrowser (or something else?), would this problem be avoided? Any other ideas to fix this problem?
The latest C++Builder supports Google's Chromium engine, it's probably safe to say it'll be compatible with Google's security upgrades.
Powerful Chromium Based WebView Component To Host Web Content In Your Delphi/C++ Builder FireMonkey Apps
We have a program that runs in IIS with Windows authentication, and which is available to the outside world.
Right now, we provide to every interested party a link to the program, along with guest credentials they then have to type.
Is there a possibility to do away with the credentials? Our internal people should be able to login as usual, but we want to provide a link to get into the guest account without typing any login credentials.
I have tried to add the credentials into the clickable url, but Internet Explorer and Edge browser do not support this, and Mobile Safari throws phishing warnings.
Can this be done universally, that the authentication is done invisibly in the background in all browsers, using some kind of redirect or XHR call with arguments or something like that?
I have a mvc4 web app that sits behind ADFS 2.0 authentication, it's configured using the web.config file. The application can be visited by going directly to a URL or as an iframe inside of CRM 2013.
The application works in all (tested) browsers when visiting the URL directly, both redirection to login form and handing the user back to the web app with the proper information in the ClaimsIdentity.
However, when visiting the app as an iframe inside CRM2013, internet explorer goes into a continous login loop. You are asked to provide the credentials (which are the same as for logging in to CRM) and when you click ok you get redirected back to the same login page again, to my knowledge the app never receives the hand off.
In Safari, Chrome, Firefox, and Opera the users are able to log into the application inside of CRM as well as outside without any problems (I'd even go as far as saying that it works better than expected for these browsers).
Does anyone have any idea of what I can try or what the problem could be for IE?
EDIT 1
I'm thinking it has to do with some security setting and am playing around with the settings in IE. Unchecking this box stops the login form from showing in IE at all and I get an empty page instead.
Is the iFrame on the same (sub)domain as the site inside? You can use Fiddler to view your redirect flow, are the cookies added as expected?
I've seen cookies that are overridden by the iFrame host, in that case you lose the auth cookie. Browsers react differently on same domain cookies.
Another problem might be X-Frame-Options, do you see any warning in the F12 console of IE?
I have vb.net 2010 and I need a way to transfer a cookie container from the program I made to web browsers like Internet Explorer, Google Chrome, Safari and Mozilla Firefox. All answers are much appreciated :)
Well, I really hope that modern browser have protection against this kind of attacks (yes, you should not be able to write/read cookies from 3 party domain such as stackoverflow.com).
If you want to implement user cookie to user browser then let it open some page where there cookie will be implemented to the browser...
In my web application, I have used the asp Login control to facilitate the login process. I have noticed that if I open the site in a browser and log in, and then open another browser and go to the site, then the second browser shows that I am already logged in, even though I didn't log in using that browser. I have noticed that some other sites (such as my bank's web access) work this way, but it still seems odd to me. I'm not sure if it's bad or not, but it is strange.
Is this behavior bad?
I have also noticed that if I close all of my browsers and then open a new one up and go to the site, I am NOT logged in.
This is because those sites use session cookies. If you open different brwosers at the same time, such as FireFox, Opera, Chrome and IE, you'll have to log in in all of the browsers independently. However, when re-using the same browser application, this usually does not spawn a new process with its own session data but rather re-uses the already open browser.
If you are using a browser that supports multi-tabbed sessions e.g. IE7+, Firefox etc, you will find that, if you have the same ASP.NET website open in multiple tabs, each tab will share the same authentication credentials. This is because the session ID applies to the browser instance, not the tab instance, so if a user logs in on 1 tab, then opens up another tab to the website, they won't have to provide their credentials twice.
I don't think there's an easy way around this behaviour. You could choose employ cookie 'munging', storing the forms authentication ticket on the URL, but this seems like a bad idea from a security POV.
Lucero and pmarflee are both correct.
To provide a bit more information though:
Firefox will share session between tabs and all browser instances
IE 8 will also share session between tabs and all browser instances
IE 7 shares session between tabs, but not across instances
IE 6 does not share session across instances
I'm not sure how Opera, Chrome, or Safari handle sessions.