I experience problems with Safari when running Adal JS 1.0.13 together with a local ADFS 4.0.
Safari: after a successful redirect back from the ADFS login screen the browser goes into an infinite loop. The sessionStorage is updated approximately 3 times/second with new values each time. If I reload the page later the same loop starts. To reach the login screen I must select “Remove all Website data”. Cookie settings: always accept.
Firefox / Chrome: login works fine and the application runs perfectly. Three cookies are available MSISAuth, MSISAuthenticated & MSISLoopDetectionCookie.
“Keep me signed in” is not selected by the user and the parameter “cacheLocation” is not specified (i.e. use sessionStorage).
Any ideas what causes Safari to behave in this way?
There are various reasons this could be happening and you will need to specifically follow up with adal.js team. See this FAQ from adal.js team.
I recommend collecting adal logs and attaching it to the github issue.
Irrespective of the root cause, the adal.js team recommends two solutions
Specify a different html for the iframe - Gist
Conditional initialization in your main app.js file - Gist
From my experience, the second approach doesn't work for anything but very basic apps. You will need to implement the first solution which takes an iFrame based approach.
Related
I am trying to create a framework for my application with webdriverio and mocha for headless and headful execution. we use basic auth for login (passing username and password in the authentication pop up), tried passing it username and password as a part of url but that is not working for chrome’s new version.any help on this is much appreciated
The credentials-in-URL method has been broken in Chrome based browsers and Safari for a while. It still works in Firefox, but it pops up an application level dialogue before loading the page and I'm not sure if WebdriverIO can see it.
WebdriverIO has no way of interacting with the HTTPAuth dialog directly. I badger Christian about this every six months or so, guess I'm due to do that again. Browserstack's documentation indicates that they do have a way of dealing with it, but I haven't tried it.
I have a site which uses are a payment service that exists inside an iframe to take the customers credit card information.
In Chrome/Edge everything is working as expected, but in Safari, when the user is redirected back to the site via the iframe (the user is broken out of the iframe when returned to the site) the user is logged out and returned to the login screen.
This is seems to be something that has happened in the last few months but this may have just not be noticed. I am trying to wrap my head around the SameSite cookie information out there as this may be related.
Has anyone experienced anything like this and have any clue as to how to resolve?
It sounds very much like a SameSite problem.
A quick way to test that theory would be to set SameSite=None and test if it now works, then work back from there.
The fact that it works on Chrome but not Safari could suggest some quirk of Safari's implementation of SameSite.
I've found the following useful in learning about this:
https://web.dev/samesite-cookie-recipes/
https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/
https://andrewwburns.com/2020/08/05/dont-be-lax-about-your-samesite-cookies/
I have started working on an Angular 10 application using DevExtreme UI Widgets. I deployed a demo version in our Azure Cloud but while I was playing with it, I noticed a strange behavior. It seems that I lose my styles when I refresh.
For example, this is how the login page should be displayed:
If I refresh the URL without entering my login credentials, the page changes and gets displayed like this:
When I login, the bad or good styles are carried over. For example, the landing page should be displayed like this:
If I refresh the screen here, I also see the styles being altered. This is how the landing page gets displayed when the styling is lost:
When I lose the styling if I keep refreshing the page over and over again, eventually I regain the styles and my application starts being displayed as intended.
Any idea what causes the styles to be lost? Any suggestion would be greatly appreciated.
Thanks,
Ed
Regarding the deployment of Angular projects, I have encountered various problems. I am willing to share it with you and hope it will help you.
Troubleshooting steps:
Solution 1.
You can deploy it via Azure Pipelines CI/CD without using the vscode to deploy webapp.
Maybe smth wrong with VS Code plugin, as it is in preview
Solution 2.
Use github for continuous deployment. It is recommended to create a webapp and choose the Linux operating system.
Solution 3.
It is recommended to use FTP to publish the build folder after the project npm build.
This issue was resolved. After further investigation, it turns out that the problem had nothing to do with Azure Cloud deployment. I use DevExtreme UI widgets in my application and the application is based on their Angular Template.
I tried the website using Chrome, Edge and Firefox. The issue described above only happened in Chrome. DevExpress tech support pointed me to this support ticket.
After following the recommendations in the workaround and a redeployment, my app looks fine even in Chrome.
Thanks for everyone trying to help.
Ed
We recently set up a series of sites such as sub1.ts.se, sub2.ts.se. We have wired them up with cross site authentication (asp.net mvc). Everything has worked as excpected. We have throughout the testing phase not ran into any issues, but as of launch, we are unable to login properly with IE.
In testphase we use the auth cookie domain .ts.se.production (wired up through local hosts-bindings). This worked just fine. Going live, changing it to .ts.se wich is the live domain name, it does not work. When changing it back to the ".production", it does work! This is the same webserver, nothing else changes.
Could this possibly be an issue related to the short domain name? I do know that IE have had issues with two letter domain historically.
Edit: The login error is that the auth cookie (wich does validate and set!) does not carry through subsequent requests/redirects, resulting in returning to the empty login screen.
From what I can gather, this IS an issue with IE and short domain names. We have resolved this by using a secondary (longer) domainname. Not a perfect solution, but works out good for us.
I have a very unusual problem that actually took me quite some time to even locate the root cause. I have an ASP.Net 3.5 web application running on Windows Server 2003. I was getting reports from users that said every so often the application would refresh on its own, without user interaction. This was unusual as I have not coded any client side refreshes. After much troubleshooting I narrowed this down to an issue with Internet Explorer (both 7 & 8). FF, Chrome, and Opera do not exhibit this behavior.
Basically, this only happens the first time a user visits the site on a new instance of IE (either a new window or new tab). If the user goes to any page within the site, and then does not interact with the site again, after 6 minutes the browser refreshes! After that refresh, as long as it is the same instance of IE, no matter what page on the site you visit, and no matter how long you let it sit, you never see the refresh again. This has really baffled me, and has become a major problem as this app has data entry forms that take longer than 6 minutes to complete. Unfortunately, if the user gets caught by this refresh bug, anything they entered is lost because of the post.
I need help!! Any advice or options to try would be greatly appreciated. Thanks!
(no, I cannot require them to use a better browser as this is a corporate environment with restrictions set to use IE for non-technical users)
It's a stretch, but maybe you have a 3rd party component that's adding a meta refresh tag only for IE (see http://www.w3schools.com/tags/att_meta_http_equiv.asp (refresh value)). Or maybe there is client-side code generated somewhere only in the case of IE that puts a location.reload() or location.href = someLocation a client-side script block in your markup.
Have you compared the HTML markup in IE and and FireFox? Are they the same? That's where I would start. If they end up being the same, look at script references and search for location.reload() or location.href.
And actually maybe before that, run IE without Add Ons enabled and see if it refreshes. To run without addons, do this at the command line, "C:\Program Files\Internet Explorer\iexplore.exe" -extoff