I keep getting the below error after deploying my ASP.NET MVC project to Azure Web Sites
A required anti-forgery token was not supplied or was invalid.
This seems like it only happens with the following steps:
Open browser and navigate to site's login page (this page may need to stay open for some amount of time) - UPDATE: This does not appear to be needed
Deploy project
Try to login
Get error
I do have the machine key specified
<machineKey validationKey="[vKey]" decryptionKey="[dKey]" validation="SHA1" decryption="AES" />
so I thought that should protect me from this happening. Any thoughts?
UPDATE: I am publishing from Visual Studio and the destination URL was set to http://[appName].azurewebsites.net instead of the custom domain that I use for FB authentication. I am on the custom domain when I actually log in so maybe there is some sort of caching issue? Not sure. As it doesn't always seem to repro, it's hard to determine if that made any difference.
I added DonutOutputCache to the ExternalLoginsList thinking I was being clever. This is a lesson in YAGNI.
Related
I have a site that is a mix of both MVC and WebForms that is utilizing forms authentication. Recently there was a need to switch from using WebForms to handle the authentication to MVC so I created an Account controller with a Login method and created the corresponding view. If someone was already authenticated and tried to visit "account/login", I wanted them to be redirected to the Index page of the controller so I have the following if statement at the top of the action:
if(User.Identity.IsAuthenticated)
There are no issues with this statement on my development machine; however, when I deploy this to the server, the User object is always null. I've searched on stackoverflow and the rest of the internet and have not yet found anything that has resolved the issue.
I should mention that the server this is running on is Windows Server 2008 Standard running IIS7.
Anyone have any ideas on why the User object is always null? I did see a stackoverflow post that mentioned it is because of the way IIS handles extensionless routes; however, when I tried to install the KB mentioned in that post it said the KB didn't apply to my server.
Okay - I finally figured out the issue.
I found a post here (http://forums.asp.net/t/1689878.aspx?HttpContext+Current+User+always+null+on+IIS+) that said the issue was because they didn't have runAllManagedModulesForAllRequests set to true. I don't want that set to true so I did a little more searching and ran across this stackoverflow posting: <modules runAllManagedModulesForAllRequests="true" /> Meaning
I checked my entry in the applicationHost.config file and found that it had the precondition of "managedHandler". Once I took that precondition off, then everything started working as expected. The odd thing is that in my development environment the precondition was there, yet it worked without issue. Perhaps it is because my dev box uses IIS 7.5 while the server uses IIS 7.0.
I have an ASP.Net MVC5 application, using the Identity "out of the box" template, as per ASP.Net Identity 2.0.0. I need to upgrade it to use the newer code that is in the latest ASP.Net MVC template, namely the use of the SignInManager class.
I have done some A|B comparisons between the code in my original app and the template generated in the latest, and ported over all that I could see what different.
However, I'm getting an odd error, I suspect OWIN related. When I try and Login or Register, it triggers a Redirect loop that eventually crashes the app with a security warning as the URL Query string has concatenated itself to death.
The URL is :
https://localhost:44302/Account/Login?ReturnUrl=%2FAccount%2FLogin%3FReturnUrl%3D%252FAccount%252FLogin%253FReturnUrl%253D%25252FAccount%25252FLogin%25253FReturnUrl%25253D%2525252FAccount%2525252FLogin%2525253FReturnUrl%2525253D%252525252FAccount%252525252FLogin%252525253FReturnUrl%252525253D%25252525252FAccount%25252525252FLogin%25252525253FReturnUrl%25252525253D%2525252525252FAccount%2525252525252FLogin%2525252525253FReturnUrl%2525252525253D%252525252525252FAccount%252525252525252FLogin%252525252525253FReturnUrl%252525252525253D%25252525252525252FAccount%25252525252525252FLogin%25252525252525253FReturnUrl%25252525252525253D%2525252525252525252FAccount%2525252525252525252FLogin%2525252525252525253FReturnUrl%2525252525252525253D%252525252525252525252FAccount%252525252525252525252FLogin%252525252525252525253FReturnUrl%252525252525252525253D%25252525252525252525252FAccount%25252525252525252525252FLogin%25252525252525252525253FReturnUrl%25252525252525252525253D%2525252525252525252525252FAccount%2525252525252525252525252FLogin%2525252525252525252525253FReturnUrl%2525252525252525252525253D%252525252525252525252525252FAccount%252525252525252525252525252FLogin%252525252525252525252525253FReturnUrl%252525252525252525252525253D%25252525252525252525252525252FAccount%25252525252525252525252525252FLogin%25252525252525252525252525253FReturnUrl%25252525252525252525252525253D%2525252525252525252525252525252FAccount%2525252525252525252525252525252FLogin%2525252525252525252525252525253FReturnUrl%2525252525252525252525252525253D%252525252525252525252525252525252FAccount%252525252525252525252525252525252FLogin%252525252525252525252525252525253FReturnUrl%252525252525252525252525252525253D%25252525252525252525252525252525252FAccount%25252525252525252525252525252525252FLogin%25252525252525252525252525252525253FReturnUrl%25252525252525252525252525252525253D%2525252525252525252525252525252525252FAccount%2525252525252525252525252525252525252FLogin%2525252525252525252525252525252525253FReturnUrl%2525252525252525252525252525252525253D%252525252525252525252525252525252525252FAccount%252525252525252525252525252525252525252FLogin
Detailed Error Information:
Module RequestFilteringModule
Notification BeginRequest
Handler ExtensionlessUrlHandler-Integrated-4.0
Error Code 0x00000000
I've used the exact same settings when referring to ReturnUrl in all methods.
For the most part, my applications' original AccountController and related security code was untouched from the original template.
My newer sample application runs fine on my local machine, so I’m not sure where the differences are.
I've seen posts suggesting that IIS Express configuration is to blame, but I've followed the cleanup advice, and also published to an Azure site with the same result.
I've been spending a lot of time trying to resolve this and haven't had any success so I thought I'd put it out there for some advice… thanks in advance for any & all help. Please let me know if you need to see more code.
I think your login action is missing [AllowAnonymous] attribute.
Do you have SSL setup locally?
Are authenticating on HTTPS then being redirected to HTTP which is killing the cookie & redirecting back to the HTTPS login page
Have you got something in the web.config for forms authentication redirect like
protection="All" requireSSL="true" loginUrl="~/Account/Login.aspx"
Do your cookies look ok?
Resolved... turns out the culprit was my Unity DI configuration.
I drilled deep to find the errors getting recursively thrown on each redirect, and it suggested the AccountController dependencies weren't being instantiated. I had a similiar issue last year Unity Container trying to resolve non registered type, throwing error , and so I looked further into the changed dependencies.
Following the suggested answer at Register IAuthenticationManager with Unity resolved the issue.
Thanks for the suggestions re: SSL / HTTPS / Filters, investigating these led me to the exceptions.
I also face this same issue before and solve by adding this line in web config
<add key="owin:AutomaticAppStartup" value="false"/>
It will disable OWIN startup discovery.
I hope it will work.
Also check in the IIS virtual directory. Check that anonymous user is enable or not, if disabled then enable it and problem will be solved.
I've installed PiranhaCMS on an existing ASP.NET MVC5 application. Part from I had to install AutoMapper, the installation went through smouthly. I followed the Get Started instruction in the "Adding Piranha CMS to an existing application". I've tried using existing database, the incluede CE database, and event with a new database. It all comes down to the same problem, I get routed to "/manager/install" where I set up the admin user (which gets added to the sysuser table). After this I get routed to the "/manager" page where I get to sign in with the user i just created. When logging in, I get back to the same page. I assume, the user is not valid... but I get no exception or other information.
Any ideas?
try to remove this node in your web.config
system.webServer/modules
What worked for me was removing the system.webServer/modules like mentioned above and also changing
system.web/authentication mode="None"
to /authentication mode="Forms"
The authentication mechanism for the manager uses Forms authentication. Since you just get routed back to the login I'm guessing Forms auth isn't enabled so the cookie doesn't get set!
Removing system.webServer/modules will disable the way MVC application (such as in defulat template) manages loging in users. Having authentication mode to "Forms" is part of getting started tutorial.
It is quite possible (and is in my case) that replacting authentication is not desired behaviour.
The question is how to let those two authentification mechanisms live side by side. I know that we'll have to keep users separated. That is fine. But how to run run two authentications side by side?
We are taking our website offline for approx an hour today and I want to redirect all traffic to an offline default page I created within the folder "offline" and the file is default.aspx. I tried using IIS7 HTTPRedirect by checking "Redirect requests to this destination;" and entering in the URL "http://webtest.ipam.ucla.edu/offline" but I am receiving a "Internet Explorer cannot display webpage" error.
please help.
I'm assuming as you're on IIS7 that your app is in ASP.NET - if not, please ignore this:
There's a nifty little feature that if you place an app_offline.htm file in the root directory of your ASP.NET application, it will have the net effect of taking your application offline.
What is the detail you see in your "Internet Explorer cannot display webpage" error? Is it really that generic or do you get some detail?
Addendum
An alternative is to add something like this into the web.config of your asp.net app (which will allow dynamic pages:
<system.webServer>
<httpRedirect enabled="true" destination="http://myurl.com/offline.aspx" />
</system.webServer>
The issue with using this approach is while you're uploading new assemblies, there is a chance your application will crash when someone hits it (giving them confusing errors) while you're making changes. Consequently, the offline.aspx page may not show properly - your mileage may vary, but this is why it's generally considered a better practice to use app_offline.htm.
I have tried googling and searching for this issue on SO - but have had little success - primarily because I am not sure whether I am searching right.
I am working on an ASP.Net Web Application Project (not website) using Visual Studio 2008, C# and Cassini for testing.
However, everytime I run the site, I get a URL such as:
http://localhost:8671/(S(saifdk55xyhalrqbstrtrdiw))/SubjectClassTeacher/Default.aspx
Even if I modify the URL and try to go to:
http://localhost:8671/SubjectClassTeacher/Default.aspx
I am redirected back to this URL.
The garbage value in the center: (S(saifdk55xyhalrqbstrtrdiw)) keeps changing every few times I compile and I have no idea why it gets injected or how to disable it.
Could anyone throw any light on this issue?
Primarily, I would like to know why this happens and how do I disable this.
Because this happens when I deploy the website on IIS as well.
Any help is appreciated.
Thank you.
This is a clever feature in ASP.NET* called cookieless sessions. It works by injecting your session ID into every URL, so ASP.NET can tell the difference between user A who visits a page, and user B who visits the same page. Normally this is accomplished with cookies, but this approach removes the dependency on the end-user having them enabled.
From MSDN:
...you don't have to change anything in your ASP.NET application to enable cookieless sessions, except the following configuration setting.
<sessionState cookieless="true" />
*The concept is not exclusive to ASP.NET, but it is baked into ASP.NET and - as you've discovered - can be turned on with no particular effort on the part of the developer.