I have a MVC application using Forms Authentication that allows users to log in as sub accounts. To accomplish this we do the following
FormsAuthentication.SignOut();
FormsAuthentication.SetAuthCookie(newMember.UserName, true);
//Set new session variables
I then redirect to a new page. The new page loads properly, with all user session specific data. However, when I attempt to navigate to another page as this user, it appears my session is gone.
This only happens in IE.
I have seen a issues similar to this, suggesting that the version of .net is not able to find the cookie store for IE browsers. However the user already has a session and only has a problem when they login as a new user.
Any thoughts?
Related
I have an ASP.NET Core 3.0 application that works with local Intranet Windows Authentication to identify logged in users. Using the standard Windows Authentication behaviors I'm able to capture the user's WindowsIdentity without an issue.
However, depending on how the user is logged into the browser using either automatic Intranet Browser login (ie. no password dialog) or explicitly logging in using the browser Password dialog box, I get different results for the user's groups.
The following is an API request that echos back user information including a filtered group membership list (that excludes built-in accounts). The one on the left is a manual login, the one on the right an auto-login.
For the explicit login I correctly see all the custom groups the user is part of. However, for the auto-login, those same groups do not show up:
I also took a close look at the User and Identity instances on the server, and it's referencing the exact same SIDs for the user, so it seems strange that different results are being returned for the Group Membership.
Any ideas why the group list is different when I am getting the same account returned? Note the groups are local so it shouldn't be an issue due to domain access.
Note: I'm testing locally on localhost even, and to test this I set the Windows Proxy Settings here:
With the checkboxes off I'm forced to login. With them on (in Chromium browsers anyway) I have to explicitly enter my credentials into the browser's login dialog.
Has the user logged out of their computer since being added to those groups?
The groups listed are held in the user's login token. I think what might be happening is that auto-login sends the user's existing login token (created when they logged into Windows), so it would not contain any groups that they've been added to since they last logged in.
Manually entering the username and password performs a new login, and thus gets a brand new token with all the groups at the time of the login. So new groups will show up there.
I am porting my idsrv3 based MVC application to aspnet-core and idsrv4.
Differently than in idsrv3 a new login is required whenever a new browser session is started. I also verified this changed behavior in the original github-samples idsrv3-aspnet5 and idsrv4-MVC and API.
In the log files I have seen that idsrv4 handles the authorize request of a new session always as not authenticated and directs me to the login. In idsrv3 the request handler immediately sends back the authorization form, when the user is already known.
Why does idsrv4 behave different?
I am encountering a strange situation with MobileFirst 7.1 where users are occasionally unable to authenticate/login. The only indication that something is awry is a message in the console.log
[AUDIT ] CWWKS1100A: Authentication did not succeed for user ID . An invalid user ID or password was specified.
My custom login module uses com.worklight.core.auth.ext.LdapLoginModule (so to clarify I have a login module which authenticates using LDAP). Like I say everything seems to work most of the time but occasionally users end up in a situation where they are unable to authenticate. I suspect that it is probably related to the session in some way, but that is only a guess based on my investigation.
I have added some logging to my 'secret' adapter which prints the session state to the console log, and obviously this appears in the logs just before the failed authentication message above, but it is empty ie. the session contains nothing.The user is obviously trying to access a secure adapter at this point, and because they are not authenticated they end up at the login page (form based authentication I should say also).
Anyway, I noticed that although there appears to be no session data, the jsessionid is there and has not changed i.e. it does not change even if I refresh the browser. This may not be an issue in itself of course, but interestingly if I remove this entry and refresh my browser I am able to login successfully.
I am pretty sure that my handler code calls the relevant success/failure methods in the correct places but of course there is nothing to stop the user refreshing their browser, which causes them to be re-directed to the login page (the app has been developed using AngularJS so is effectively a single-page navigation model).
The only reproducible test I have been able to come up with is when I login to the MobileFirst console and then try to login to our MF 'desktopbrowser' app. I have read that this situation causes a session-related conflict, but as I say the occasional issue I am seeing is not caused by this (though it may be related).
So the problem seems to have been more related to the flow of logic in our application after successfully logging in, than any inherent issue with the MF Platform.
For example when a user refreshes the browser they are effectively still logged in, but because the app (based on logic we have developed) takes the user to the login page on refresh, the user is effectively re-logging in to the same session. If this failed every time it would of course have been easier to pinpoint but it does not. The solution was to force logout on refresh (when the app initialises), thus cleaning up any session data. In future iterations it may of course be better to re-establish the application based on the authenticated session after refresh, but at present that was a step too far.
Another example of this was post login if the subsequent adapter calls failed (e.g. we authenticate and then retrieve profile data from a database), then we were also not logging the successfully authenticated user out.
We are trying to build OAuth2 Authorization with IdentityServer3.
So we downloaded the Bytes from nuget and connected it with our database.
The database was initialized with the default scopes and the sample clients from Thinktecture self.
Then we connected AD FS as IDP via OWIN and made an simple ExternalUserService.
So far everything worked fine and the permissions page of the IdSrv could be opened, showing the username and that no application has consent up to now.
Then we tried to connect Xamarin.Auth to that and got an error Cannot determine application to sign in to and in the logs an error Signin Id not present (after logon at the ADFS IDP).
To reduce complexity, we decided to go back to the InMemoryUserService and created one InMemoryUser. This worked for the permissions page (at least for a short period of time - time is over now), but it did not allow OAuth2 Authorization Code Flow, which ended up in showing the login page again and again and again. And there is no evidence of any error in the logs.
How can we debug, what is happening? Is there any way to see, why a user gets redirected to the login page again despite being logged in?
--
We reduced the complexity even further by creating a new empty MVC application, which just uses a simple InMemoryUserFactory.
Now it's getting a little bit confusing: one user was able to logon from his machine - other machines (same user - since we created only one) are not able to login and get prompted with the login over and over again.
If using IdentityServer3 and you use own external login methods you should really pay close attention to the API of the IdSrv3.
We tried to create a login resutl with just the subject - this is made for local login on the server. If this is switched off at the same time, you will end up having problems.
So if you use an own external login provider and switch off local login, make sure to call the right overload for the authenticate method (3 Parameters in our case).
I'm very new to liferay and am creating a hook on the login.events.pre event. My users will be signing in to the website by using their phone number, so I have to do some validations on the status of their phone line before letting liferay create a session for the user. I've already created the portlet and am able to execute some java code before letting liferay take care of the login validation, but I'm not sure how to stop the whole process if my validation fails. In other words, if I find out that the users phone line is suspended, I don't want liferay to allow them to sign in, even if the right login info has been provided by the user. Is it possible to do this in the login.events.pre event in liferay?
In this case you can invalidate the Session and redirect it to some customized error page in your hook.
Below piece of code might be helpful.
//Below code to get the current session
HttpSession session = null;
session=request.getSession(false);
//Below code to invalidate the session and to redirect to your customized error page
session.invalidate();
response.sendRedirect("/errorPage.html");