I'm currently using the asp.net membership provider (with logins stored in db) to protect certain pages of my site. However, I also have non .aspx resources I wish to protect - word docs, excel spreadsheets, pdfs, etc. Is this even possible? If so how would I go about doing this?
thanks!
If you are running IIS 7 under the integrated pipeline (the default setup), all requests go through IIS. This means you have to do nothing other than setup your web.config. You'll need to do one little thing though, put the following attribute on the modules node under system.webServer:
<modules runAllManagedModulesForAllRequests="true" />
This ensures that the forms authentication modules run for your static content.
Related
We have an IIS7 intranet site running under integrated pipeline that is mostly ASP.Net with a few legacy classic ASP pages. The site allows anonymous access to most areas, but uses Windows Authentication to protect certain folders. Requests to ASP.Net pages in the protected folders behave as expected (authorized users can see them, others are denied), but any user can see any classic ASP page in the protected folders, regardless of permissions.
I suspect the windows authentication module is not being invoked for requests to classic ASP pages. We're running in integrated pipeline mode, and I found this article (http://learn.iis.net/page.aspx/244/how-to-take-advantage-of-the-iis7-integrated-pipeline/) which indicates that you need to explicitly remove and re-add modules if you want to take advantage of the integrated pipeline for non-ASP.Net requests. I tried to copy the article's example only replacing FormsAuthenticationModule with WindowsAuthenticationModule by adding the following to the web.config at the application root:
<system.webServer>
<modules>
<remove name="WindowsAuthentication" />
<add name="WindowsAuthentication" type="System.Web.Security.WindowsAuthenticationModule" preCondition="" />
</modules>
</system.webServer>
However, classic ASP pages are still being served regardless of permission.
Classic ASP pages totally ignore web.config or any .config actually.
The only way to handle this for classic ASP is through IIS, you will have to move the classic ASP pages to be under separate virtual website then for that virtual website set Windows Authentication and disable Anonymous Access.
This might help you as well:
IIS7: Setup Integrated Windows Authentication like in IIS6
I am trying to run two web application using the same ASP.NET membership provider database that comes with MVC3. So two web app runs side by side and they both has the same connection to the same membership databse. The problem now is, I can only login at one app and get automatically log out at the other. However, the feature I want is, if I log into either one, I get automatically log into the other.
I was wondering what the trick is to enable this feature.
thanks a lot
If you are using Forms Authentication users are tracked with cookies. Cookies are by default restricted only to the application that emitted them. And because of this the other application cannot see the authentication cookie created by the first. So for example if you have the two applications hosted respectively on foo.example.com and bar.example.com you could set the domain property of the cookie in web.config of both applications to example.com:
<forms
loginUrl="/login/index.mcp"
requireSSL="true"
protection="All"
timeout="120"
domain="example.com"
/>
This way the cookie will be shared among those two applications and you will be able to achieve Single Sign On.
Finanlly I fixed it.
My application runs under the same domain so domain is not a problem (But Thank you very much, Darin).
The problem is:
IIS by default generate differnt machine key for differnt web application. So I have to specify the same machine key in web.config explicitly~!
I've created a web site with ASP.NET 2.0 and I'm using a session variable to determine if a user has filled out an age verification form. Everything works as expected (I can read the session variable on all pages) until a user goes to a virtual directory. When they do so, the page can't read the session variable.
After much research, I've so far done the following.
Turn on the ASP.NET State Service
Added a sessionState node to my web.config files, changing the mode to StateServer (for the web site and virtual directory).
<sessionState
mode="StateServer"
cookieless="false"
timeout="20"
stateConnectionString="tcpip=127.0.0.1:42424"
/>
Generated a new machineKey and added it to both the site and the virtual directory...
<machineKey
validationKey="...128..."
decryptionKey="...64..."
validation="SHA1"
decryption="AES"
/>
Created a new application pool and made sure both the web site and it's virtual directory are using the same application pool.
If I write out the session id <%= Session.SessionId %> it is the same on pages in and out of the virtual directory (it's the same throughout the site). I just can't get that session variable! Does anyone know what else I can try to get this to work??
Thanks.
Different virtual directory = different application and applications don't share session data between them. Perhaps a redesign of your applications to avoid this?
Here is a possible solution to sharing session data between ASP.NET applications.
Passing session data between ASP.NET Applications
From everything I can tell, it's not possible to do what I wanted to do. What's worse, I decided to use cookies instead of session variables, thinking that since cookies are created and maintained by the client and based on the domain, that would work. Unfortunately, somehow when created with C#/ASP.NET even cookies can't be shared. So I had to use C# to insert Javascript to create cookies so I could do what I wanted. End result is an inelegant solution to what should be a simple problem (IMHO).
I am trying to set up Single sign on for 2 websites that reside on the same domain
e.g.
http://mydomain (top level site that contains a forms-auth login page)
http://mydomain/admin (seperately developed website residing in a Virtual Application within the parent website)
Have read a few articles on Single Sign on
e.g.
http://www.codeproject.com/KB/aspnet/SingleSignon.aspx
http://msdn.microsoft.com/en-us/library/dd577079.aspx
And they seem to suggest it is just a case of having the same machinekey section in each web.config so that the cookie encryption and decryption is the same for each application
I have set this up and I never get prompted for credentials in the sub-website (the virtual application)
I always get prompted in the parent site.
In addition to having the same machinekey I've also tried adding the same <authentication> and <authorisation> elements
Any idea what I could be missing?
Your forms section of web.config needs to be the same as well.
Quote from - Forms Authentication Across Applications
To configure forms authentication across applications, you set attributes of the forms and machineKey sections of the Web.config file to the same values for all applications that are participating in shared forms authentication.
The following example shows the
Authentication section of a Web.config
file. Unless otherwise noted, the
name, protection, path, validationKey,
validation, decryptionKey, and
decryption attributes must be
identical across all applications.
Similarly, the encryption and
validation key values and the
encryption scheme and validation
scheme used for authentication tickets
(cookie data) must be the same. If the
settings do not match, authentication
tickets cannot be shared.
I had used <clear/> on the httpModules section, as there were items in the parent that did not exist in the bin dir for the child (/admin)
In doing so (using <clear/> that is ) I had inadvertently cleared the FormsAuthentication module specified in the web.config in
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG
so i needed to re-add those explicitly to the child (/admin) config
Try configuring the httpCookies section in the web.config of both applications to use the same domain. That way when you log-in to one app the FormsAuthentication cookie you get will be visible to the other application.
You need to have the same authentication elements in the web.config. In the contained forms element, make sure you give each application the same value for the name attribute. For the loginUrl attribute, I use a relative path and use the same logon page for all of the applications (e.g. loginUrl="/MainApp/login.aspx").
Also, are you creating the authentication ticket manually?
There is a breaking change in ASP.NET 4.5's token generation
If you're mixing ASP.NET 4.5 apps with apps targeting earlier versions, you will need to ensure compatible tokens are used everywhere. Add this attribute to the <machineKey> on any site targeting .NET 4.5 or higher:
<system.web>
<machineKey compatibilityMode="Framework20SP2" />
</system.web>
See this answer for more details. Special thanks to this comment which pointed me in the right direction.
On Apache/PHP sites if I want to put a senstive file within my website folders, I put a .htaccess file in that folder so users can't download the sensitive file.
Is there a similar practice for IIS/ASP.NET sites, i.e. if I have a shared hosting account and don't have access to IIS server. Can I do this in web.config for instance?
e.g. the ASPNETDB.MDF file that ASP.NET Configuration put in the App_Data directory. I would assume this is protected by default but where can I change the settings for this folder as I could with a .htaccess file?
Inside of an ASP.Net web.config you can setup locations to add security to specific files and folders. In addition, you can remove all verbs from those directories:
<location path="Secret" allowOverride="false">
<system.web>
<authorization>
<deny users="*" />
</authorization>
<httpHandlers>
<remove path="*.*" verb="*"/>
</httpHandlers>
</system.web>
</location>
I have only used the authorization portion of that snippet and it works great. The handler should further lock it down and using a ISAPI filter would be able to put the finishing touches on it.
Well, if you can access IIS settings, UrlScan can help. For IIS 7, request filtering can help a lot.
http://learn.iis.net/page.aspx/473/using-urlscan
http://learn.iis.net/page.aspx/143/how-to-use-request-filtering/
There are some things you can do with web.config like defining security settings etc...
Other times you have to use HttpModules or HttpHandlers, look here:
http://msdn.microsoft.com/en-us/library/aa719858(VS.71).aspx
If not, you can find different ISAPI, but in this case you need access to IIS.
For example, the ISAPI for emulating rewrite mod apache:
> http://www.codeplex.com/IIRF
The other question, yes ASPNETDB.MDF in APP_Data is protected normally (it depends on your administrator). To change the path, change the connectionstring.
There are two cases:
If the server is using IIS7 then there is equivalent functionality available using the web.config approach for all files.
If the server is using IIS6 or earlier (and for the time being this is by far the most likely case for shared hosting) then its more of a problem. If you can force all your requests to go via the ASP.NET handler (which normally requires access to the server to configure) then again the web.config approach will work but otherwise you're going to need other tools and a sympathetic hosting provider. For this reason alone one probably wants IIS7...
That said for asp.net there are files that are protected by default anyway - files in app_data as already mentioned plus specific file types (like .config). Additionally one would expect a decent host to provide a directory that is not accessible via the web - ours offer a private and a web folder, both accessible via FTP but only the contents of the latter via the web.
As per the [documentation on Application Folders][1], IIS won't serve requests to content stored in the /app_data folder although your application can read and interact with those files.
ASP.NET recognizes certain folder names that you can use for specific types of content. The following table lists the reserved folder names and the type of files that the folders typically contain.
Note
The content of application folders, except for the App_Themes folder, is not served in response to Web requests, but it can be accessed from application code.