Auto windows login #6
Comments
|
You could do the following: 1. Startup.Auth.cs: Change LoginPath = new PathString("/Windows/Login")2. AccountController.Windows.cs: Update [AllowAnonymous]
[AcceptVerbs(HttpVerbs.Get | HttpVerbs.Post)]
public async Task<ActionResult> WindowsLogin(string userName, string returnUrl)
{
.
.
.
}3. Web.config: a) Update Windows Login Handler registration to allow GET/POST <add name="Windows Login Handler" path="Login" verb="GET,POST" type="MixedAuth.WindowsLoginHandler" preCondition="integratedMode" />b) Add a custom error page configuration, as described here. But make the 401.html automatically redirects users to the normal Login action: <!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
<meta http-equiv="refresh" content="0;URL='/MixedAuth/Account/Login'" />
</head>
<body>
Invalid credentials
</body>
</html>4. AccountController.cs : Make sure that |
|
This approach doesn't work for me. Should it work having "Anonymous Authentication" = Enabled? |
|
Are you sure you followed the steps exactly as described ? Try them on a fresh copy of the repository, and pay attention to step 4. |
|
Also note, the repo. has [Authorize]
public class HomeController : Controller
{
[AllowAnonymous]
public ActionResult Index()
{
return View();
}
}Does this help ? if not, what URLs are making the loop ? |
|
Thanks for so quick response. It's being late here, so I won't argue too much about what I missed - it might be really so.:) However it looks like I did everything like you described. Regarding the 4 step - it's about logoff logic, but I'm not being logged in, so probably it's not the case. Although I implemented it in a slightly different way - without 401.html page with Meta-refresh, which looked strange for me. Not sure if AuthenticationFilter is neccesary here, might be something similar can be achieved just using one of global.asax life-cycle methods.. |
|
The 401.html approach is least invasive, as it does not mess with the flow. It requires no additional configuration. You excluded the login action from your filter, what about other anonymous actions! do you need to keep excluding them too ? |
|
The 401.html approach didn't work for me, because it wasn't happening automatically by some reason. What you mean by "requires no additional configuration" is also not clear, because you pointed 4 steps of additional configuration yourself. :) I just configured/developed it in a slightly different way. Regarding anonymous access - it's a bit more complicated here, because user always can logout and continue browsing anonymously. Automatic windows login is needed only for the first login. So to what my filter will be attached and to what it won't - it's not so critical, it's just a matter of the first access to a site. |
|
I meant no additional configuration after initial setup 😄 Why not to make a fork and share your modifications, I'm not sure I do understand what you did! |
|
What I did - I think it's a bit too specific for my app. |
|
That would be great! Thanks. |
|
Hi Mohammad, Thanks for coming back to me so quickly. My intention is to determine whether the user is a member of particular AD groups. I believe the best way to do this would be by adding the following to the WindowsLogin method in AccountController.Windows.cs: Do you agree? How would you then redirect to the forms login route? Would the LoginPath option of the "UseCookieAuthentication" need to be changed? |
|
Hi Adam, Yes, I would add such logic there! and No, you don't need to change the LoginPath. Following the same flow as when the windows user name is already used by another local login, the user is redirected to One last thing, be aware that not all AD groups are available using |
|
Thanks for That Mohammad. So in the if (!membershipPass) condition, I could just call: return View("Login", new LoginViewModel { }); |
|
Yes, it will act the same as when the user is not windows authenticated: //
// POST: /Account/WindowsLogin
[AllowAnonymous]
[ValidateAntiForgeryToken]
[HttpPost]
public async Task<ActionResult> WindowsLogin(string userName, string returnUrl)
{
if (!Request.LogonUserIdentity.IsAuthenticated)
{
return RedirectToAction("Login");
}
.
.
.
} |
|
Of course. Thank you. |
|
Hi Mohammad. Sorry, another one for you. Once logged in, I want to retrieve data from other tables. Would you add a secondary DB Context to interact with these new tables? The reason I'm asking this is because at the moment ApplicationDbContext is derived from IdentityDbContext, rather than the normally used DbContext class. Does this make sense? |
|
Have a look at this question and answer |
|
Thanks Mohammad. Got that sorted now. Something needs to be updated to get the Logoff working correctly. Currently, in LoginPartial, "LogOff" is called. I'm guessing some kind of conditioning is required here to determine whether to call "LogOff" or "WindowsLogoff"? If I change LoginPartial to call "WindowsLogOff", the AuthenticationManager.SignOut() method is called, and it goes to a blank page. I guess here, I'd need to redirect to a "You have successfully Logged out page"? Also, When calling the SignOut() method, shouldn't the records be removed from the "Users" and "UserLogins" tables, or should they remain in there? |
|
The You should be calling the normal As for "Users" and "UsersLogins" tables, these hold the registered users along with their linked logins, you should keep them as long as you want to keep your users! |
|
Hi Mohmmad, I've done that, however, the ProcessRequestAsync is called, checks whether context.User.Identity.IsAuthenticated is false (which it is), and then logs on again. This is due to the change we made above to automatically login as Windows, by changing the LoginPath variable to "//Windows/Login". What would be cool, is if after "LogOff" is called, and AuthenticationManager.SignOut() is run, the original Forms or Windows login page is shown. I've tried this by calling return RedirectToAction("Login", "Account") after AuthenticationManager.SignOut(), and it seems to work. Does this look valid to you? Do you reckon anything else is required to completely logoff? |
|
As I said before:
|
|
ok Thanks. So my change above should be sufficient then. Thanks again. |
|
Hi Mohammad. Thank you for all of you help in the past few weeks. Its been really helpful to me. I have tried to merge in the MixedAuth code into the project to allow internal users to login automatically. However, I have had difficulty in merging in the code. Thus far, the Windows\Login method isn't auto called for some reason. If manually type in the Windows\Login path, the ProcessRequestAsync is called, but isn't run through the second time for the secondary request, like in the MixedAuth project. Instead, after running through the ProcessRequestAsync code once, it fails, reporting "The custom error module does not recognize this error.". Long shot, but would you have any idea what this means? I can't even see where it is being generated from. |
|
Additionally, since upgrading to Update 2, if I open the original MixedAuth project, the "DefaultConnection" database won't create when trying to register a new user. It states: |
|
Moved to a new issue #11 |
Hi Mohammad,
This is a very good example of mixed authentication. Thanks for this. With this example, how would you go about automatically attempting to logon via Windows authentication (i.e., not having a "Windows" login button on the view), so when the application is loaded, it automatically attempts to login via Windows authentication, and if it fails, to display the Forms login view?
The text was updated successfully, but these errors were encountered: