Some of our customers are having problems logging onto our site using Safari.
We have 3 sites, Main,Login and API, they are all running .NET Core 2.1.
Login is using Identity Server 4 with OIDC.
For the customer: They login in and then the page turn white.
Looking in the log it seems to log in, redirect to the main site, the main site redirects back to the login site (because it thinks the user is not authenticated) the login in site thinks they are logged in and redirects to the main site and gets stuck in a loop.
I have seen that Safari cookie size might be an issue I changed to MemoryCacheTicketStore to reduce cookie size, did not help.
One particular customer gets this problem 2-6 tries, then on the next try it works.
We have many customers that use Safari without any problems so it is not a problem for all customers.
I haven't been successful in reproducing the problem either.
Any suggestions on a solution or perhaps how to dig deeper into the problem?
/Jimmy
I have found a topic that explains a reason why IdentityServer has issues in Safari. https://github.com/IdentityServer/IdentityServer4/issues/1278. Unfortunately, haven't found a proper decision yet.
Related
I'm currently working on an ASP.NET MVC project and I'm using an azure AD to connect to my website.
When I try first on Chrome, for exemple, those are the cookies that are created :
And every thing works fine ! But if I launch the same website on FireFox without stoping IIS express, I got an infinite number of cookies incoming and the server stop and says :
HTTP 400. The size of the request headers is too long.
And got this list of cookies :
If I close IIS Express and retry an other time with FireFox, it created only 3 cookies and works fine...
Can Someone explain me what is going on ?
PS: Please don't give the solution " you need to delete old cookies" it's not the problem here... It doesn't work even if I don't have any cookies... AND nothing matters what browser i'm using, I've tried 6 differents browsers and every time only the first who has been launch is the only one who works.
Thanks in advance for your help !
Reason/Investigations
I think you have some API or AJAX calls which are secure and require authentication. When you change the browser and your requests are no more authenticated and on AJAX or API call it start creating the cookies. I am sure if you will login to the app in FireFox it will stop doing that. I dont think it is a browser specific issue. If you will move the app from Firefox to IE it will do the same.
Solution
Now, you have to either make sure that when you are not logged in or the request is not authenticated you redirect to login page and stop making unauthenticated calls.
Other solution is to delete all nonce cookies as per MikeDotNet solution.
You will find some people suggesting that it is a bug in Microsoft Nuget package Microsoft.Owin.Security.OpenIdConnect and if you use 3.0.0 it will fix the problem. It works in some of the cases but I found that solution good for IIS but not in Cloud.
I've been researching this a lot lately and cannot seem to find a solution to the exact problem I'm having, so I figured I'd ask and get any help I can get.
Here's the scenario: I took over a Sharepoint web application that was in development for a client. I finished adding the rest of the content for him and he wanted to go live with the site once I finished. I am wanting to make the entire web site (web application) public so I completed the steps to allow anonymous access for the entire web site.
The problem I'm encountering now is that every time someone goes to the site, it pops up with a window asking for the username and password. When you cancel it, then the site pops up as it should and you can view anything on the site. However, each time you click to go to the Home page (default.aspx), it pops up with the Windows Security again. Basically you can view the whole site as intended without logging in, but the popup happens each time going to the default.aspx page to where you have to keep cancelling to continue viewing the site. Of course this needs to stop since the site will be public for users and many do not have a log in. This obviously will confuse people trying to see the site because they'd think they need to log in.
Does anyone have some suggestions to why this is happening and how to stop it? None of the other Sharepoint sites we've made have had this issue when enabling anonymous access so it's not an issue we've come across before. I've looked at the other sites and how they're set up and it looks identical to this site that is having the popup issue. There's also not been a need before to adjust IE Internet Option settings since that was one solution I've seen.
Any help would be appreciated. I've tried researching and couldn't find a solution I needed and I'm at a loss. I can provide any additional info if needed. Thanks!
This can happen (and most probably) if a resource is not published in your site. Make sure to publish all your resources (Images, CSS & JS files.. etc) and then give it a try.
I am implementing a bookmarking service (think Instapaper) using Firebase as a back end. Mostly it's working great, however I'm running into one major problem.
A core part of the service will be a bookmarklet that allows users to bookmark pages they are currently viewing in their browser (again, like Instapaper's: https://www.instapaper.com/save).
The first problem I encountered when implementing this was that even when a user is logged in on my firebaseapp.com page, that user was not showing up as authenticated when the javascript from the bookmarklet was fired. I figured out this was most likely due to cross-domain issues, so I next implemented an iframe-based solution. The idea being that the url of the iframe is hosted on my firebaseapp.com site, allowing the currently-logged-in user to show up as authenticated.
This works great in Chrome and Firefox but fails in Safari when the security setting for cookies and website data is set to "Allow from websites I visit" rather than "Always allow" (asking users to switch that setting to "Always allow" is not practical).
Is there any solution to this problem? Forcing users to log in every time the bookmarklet is clicked on a new domain would be highly inconvenient. I'm basically out of ideas at this point (and starting to get out of my depth on the web dev side of things).
Thank you so much for any help!
Here is the problem that I'm having. Often times, I cannot login to my Plone site. Other users have the same issue as well. Basically what happens is that when I click "Log In", the web page just refreshes but it doesn't log me in. In order to correct this problem, I had to clear the browser history and cookies in order to log in successfully. Sometimes I had to do this a few times in order to work. I would like at least 50% of the time I had to clear the history before I can login. Other times, it just works and it logs me in without any issue.
This problem started quite some time ago, perhaps almost a year now. I just never had time to look into it. However it seems like this problem is related to newer version of web browsers because I never had this problem before around one year ago.
I'm running Plone version 4.0.4. Can anyone suggest how I should troubleshoot this problem? Should I upgrade a particular component within my Plone setup?
FYI, I'm using the building authentication component and not anything external like LDAP. I manage my users in Site Setup -> Users and Groups.
Thanks in advance.
Things to look into:
go to /acl_users/session/manage_propertiesForm and check the settings here to make sure they make sense
check cookie settings for if they are valid on non-ssl and that you are logging in via ssl urls.
use a web browser web inspector(like chrome) and inspect that login cookies are set properly after you're logged in(look for the __ac cookie)
Finally, look into your caching. If you're using plone.app.caching, make sure to NOT cache for logged in users. If you're overriding caching at the web server, make sure you're not caching when the __ac cookie is present.
If you're not caching at the web server, make sure cache headers for the browser are also getting set appropriately
inspecting caching will also require using a browser to inspect the headers getting returned
We have a site on asp.net framework 2 (dashCommerce cms)
Month ago we noticed an error — one guy couldnt loggin from chrome on his own laptop. System didnt display any error messages, just redirected on main page in unauthorized state.
We couldnt reproduce the same issue on our computers in the same browser (btw it was chrome)
and decided that it had been connected with some undefinded local issue of that guy's laptop.
But then, i got the same issue on my computer. I couldnt login in the system in chrome. Other browsers worked excellent. And we could see the problem only on my computer. We tested the site on 5 different computers with exactly the same chrome version, and everybody could login excepting me.
It looked like asp.net authorized me successful (because if i entered wrong password i got a message about it) but chrome didnt accept cookies.
At this moment, i have that problem on my two computers, and i cant login using Chrome, IE and Opera. Only FF can login with no issues.
But other guys can easily login using such browser from them own computers.
We've been already spent almost two week puzzling our heads what the hell is going on. Nothing helps.
I noticed:
1. Even if i cant login, nevetheless the browser keeps the session — i can add few items in shopping cart and it wont be deleted. I can try to login, then check out the shopping cart and would see those added items.
If i change coockieless attribute to «Uri» then authorization worka fine, i can login using all sort of browsers, but in this case the site has terrible links, we cant allow it.
It makes me think that the problem is connected with a session but i cannt understand why i can login from another computer (the same browser, the same Windows7)
Does anybody has any ideas???
Could be related to page caching. You are logged in but receive a cached (not logged in) version of a page.
Try turning kernel mode caching off as a start.
And like Gregory said - capture your requests and see how it works. Pay special attention to set-cookie http headers.
forgot about this question.
We solved the problem: removed standard asp.net auth form and developed common form with manual processing of authorization.