I am making a ASP.NET web page in C#. I'm finding that if the web page is left alone for a short period of time, I start getting 401 Unauthorized Errors whenever the page attempts to call a WebMethod. I think this is probably caused by the Session timing out.
I only make use of the Session for a short time when the user first enters this page, when I am doing some backend caching and using the Session to keep track. At that time the page is hitting the backend continuously for updates, which would be refreshing the Session. Once this is finished I no longer need any Session state.
Is it possible to have a WebMethod that works without requiring a session state, but it able to find and access it if it one exists? Or if it created an empty session automatically when the WebMethod was called, this would also be fine.
Thanks!
apart from the ans given by #Jupaol
you can easily use Location element of web config
with something like this
<configuration>
<location path="Url_To_WebMethod">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>
</configuration>
this would remove the need of authentication from your web method and then you would be able to use it without requiring any auth cookie
Well if my understanding is correct, you should place your Web Service in a sub-folder and configure it to allow anonymous users:
Your typical root web.config would look like:
<authentication mode="Forms">
<forms loginUrl="~/Account/Login.aspx" timeout="2880">
</forms>
</authentication>
<authorization>
<deny users="*"/>
</authorization>
In the sub-folder, create a new web.config file and override the authorization settings:
<?xml version="1.0"?>
<configuration>
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</configuration>
Related
I have created a brand new web form application from Visual Studio 2013 and set the following in the web.config file:
<authentication mode="Forms">
<forms defaultUrl="~/Home.aspx" loginUrl="~/Login.aspx"
slidingExpiration="true" timeout="2880" />
</authentication>
<authorization>
<deny users="?" />
</authorization>
When I run the project I get 404.15 error.
This is not an MVC site.
I found a similar error that said I need to remove the "deny users" but I don't want to do that.
I need all users to be directed to the login page if they have not authenticated.
* New Asp.Net MVC5 project produces an infinite loop to login page *
I also tried this but I get "This webpage has a redirect loop"
* How to configure the web.config to allow requests of any length *
EDIT: Added more links to explain the problem.
So I found and article about login page loops.
* http://erlend.oftedal.no/blog/?blogid=55 *
So if I add a break point on the ProcessRequest I can see that there is an infinite loop calling the Login.aspx page.
So the problem does not seem to be that the URL is too long but more likely that there is an infinite loop calling the Login.aspx page.
If I place a breakpoint on the Page_Load in side the Login.aspx page, the breakpoint never gets hit.
There must be something higher up causing the redirect.
Here is how I got it to work.
Excluded all the items under the Account folder except Login.aspx
Excluded IdentityConfig and Startup.Auth under the App_Start folder
Excluded IdentityModels under the Models folder
Excluded Startup under the root folder of the application
Commented out all the code under Page_Load and LogIn inside the Login.aspx code file
Commented out code with OpenAuthProviders in the Login.aspx markup
Added the following key to the appSettings section inside the web.config file
<add key="owin:AutomaticAppStartup" value="false" />
The solution it's not completely deactivating the whole authentication system.
The problem may be caused by the access control not correctly setting Login.aspx permission when using the FriendlyUrls module. So you must force the permissions also for the Login page by it's "friendly" name. In the folder where login page it's stored, possibly will already be a web.config file that you may setup like this:
<?xml version="1.0"?>
<configuration>
...
<location path="Login">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>
<location path="Login.aspx">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>
...
</configuration>
Note: Take care with other pages currently in the same folder and setup accesses accordingly.
ASP.Net 4.0 application, using Forms Authentication, timeout="1". The redirect page is Login.aspx.
As soon as I log into the application, I am taken into a default page (Page A), and if I wait idle for 1 minute and then try to access another page (Page B), I am re-directed to the login page (correctly).
If however, as soon as I log in, I access Page B and wait idle for 1 minute and then try to perform some other postback action, I am allowed to do so (where as I should be thrown back to the Login.aspx)
Am I missing something here?
Make sure the all the required folders are managed by FA...
<system.web>
<authentication mode="Forms">
<forms name=".AUTH_COOKIE" loginUrl="~/login.aspx" protection="All" timeout="2880" requireSSL="false"/>
</authentication>
</system.web>
Then, just after the system.web element of the web.config, add as many of these entries as are required to secure folders (remember, leave out the initial forward slash - all paths are absolute by default)...
<location path="securefolder">
<system.web>
<authorization>
<deny users="?"/>
<allow users="*"/>
</authorization>
</system.web>
</location>
EDIT:
Keep in mind that sub folders of secured folders are secured by default - the allows the specification of multiple folders that are not nested.
First off, I am only now familiar with with the issues with regard to Autorization and JSON services. See:
How to manage a redirect request after a jQuery Ajax call.
My situation:
I have an admin directory, with its own "admin" directory, denying unauthenticated users:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<authorization>
<deny users="?" />
</authorization>
</system.web>
</configuration>
Within this directory is my main page and two Http Handlers which I'm using for uploading files and what not. Now, while I've got code to handle the situation when a user is unauthorized when the handler is accessed via GET or POST, it seems the handler is never executed, and the GETs/POSTs get redirected to the login page. I suppose this is all well and good, but I'd really like the http handlers themselves to handle the issue and handle it differently (at least give something like a 401 code instead of redirecting).
It seems like it should be fairly easy (and I bet it probably is easy) to poke holes to allow the HTTP handlers to handle their own security, but I'm kinda at my wit's end here, so I was hoping somebody would kindly show me how I need to modify the web config to allow those services to handle their own authorization. Thanks!
Have you tried specifying for each one?
<location allowOverride="false" path="Content">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
<location allowOverride="false" path="Scripts">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
Be careful. Order matters. So least restrictive to most restrictive top to bottom.
Today I moved my application from a server with IIS6 to a new one with IIS7.5 (windows server 2008 R2).
The odd thing is that I cannot access the default document although it has been set in the default documents section. The file is the "deault.aspx" and when I try to access the page with ip I am getting http://[IP]/login.aspx?ReturnUrl=%2f, but it works fine If I access it directly.
This is the settings from web.config
<authentication mode="Forms">
<forms protection="All" loginUrl="login.aspx" name="CookieName" timeout="49200" requireSSL="false"/>
</authentication>
<authorization>
<deny users="?"/>
</authorization>
<location path="Default.aspx">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>
I've already tried to solve this with some of the suggestions that are written here [ Forms Authentication Ignoring Default Document ]
, but with no luck.
I want to solve it by configure somehow the server and not the application.
Thanks
SOLUTION
I don't know if it is the correct one, but I change the mode of the application pool into classic instead of integrated.
Add the following to the web.config and it will allow you to access Default.aspx without requiring prior authentication. All other pages will require authentication.
<location path="default.aspx">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>
Just because a document is added as the default within the IIS configuration does not mean it bypasses the FormsAuthentication.
For me, removing the ExtensionlessUrl-* handler mappers in IIS Manager for the site in question did the trick. Even though all this does is adds the relevant entries to web.config that I had already tried with no luck.
My website should have some parts that can only be seen when the user is authenticated, some parts that are visibile to everyone.
The forms authentication always redirects the user to the login page no matter what page is visited. Does that mean I should not use forms authentication? How can I solve this issue?
Use <location> element in web.config to set which pages are protected. You need to remove the authorization from the whole web site set it for each protected page in the <location> element.
A common approach is to place all protected pages in a separate folder and specify the location path to that folder.
Another one is to have a class which inherits System.Web.Page and at the Init event to redirect the user to some page, if is not authenticated. Every page should then inherit this page.
<system.web>
<authorization>
<deny users="?"/>
<allow users="*"/>
</authorization>
</system.web>
<location path="public">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>
<location path="login.aspx">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>
For me, the problem was the MachineKey. It's required to decrypt/encrypt the cookie if you are doing that (for example: a web farm). Because the app couldn't decrypt the cookie, even though it was getting passed back and forth, the app acted like the cookie wasn't even there. Adding this setting to web.config fixed it for me:
<machineKey compatibilityMode="Framework20SP2" validationKey="some_hard_coded_long_key" decryptionKey="another_hard_coded_long_key" validation="SHA1" />
See this article for more on the machinekey.