My question is, Can I Check session before allowing user to view a file, e.g:
http://www.somedomain/pdf/dummy.pdf
When user clicks on this url I want to check whether the session is valid or not, If session is valid allow user to view/download the file otherwise take the user to Login page.
Thanks.
You can write HttpHandler and set it to process *.pdf files. IHttpHandler.ProcessRequest method has access to HttpContext so you can access session information and do pretty much all you want...
How to setup handler for PDF files depends on IIS version but here's an example of doing it via Web.config file for IIS 7 in integrated mode. For versions prior to 7, Web.config file change is not enough, you also have to use IIS Manager to map extension to Aspnet_isapi.dll. Look here and here for details.
Your question is a bit vogue. Maybe you don't want to access HttpSessionState, instead you just want to use standard ASP.NET URL authentication on static files (such as PDF)? If so, search for "ASP.NET authorization for static files", this is quite popular topic.
This is what I wanted to do. Thank to: #skhurams
http://www.mikesdotnetting.com/Article/122/Simple-File-Download-Protection-with-ASP.NET
Related
I often use #{ Html.RenderAction("Method", "Controller"); } in my views to embed additional content. Due to a bug, such a RenderAction tried to access a controller who was decorated with [Authorize] although the user wasn't logged in.
Then something scarry happend: When the page was loaded, the browser opened a form and asked for credentials. The form looked like to one you see when you try to access a password protected directory (via .htaccess).
Via trial and error, I was able to log in - by using the credentials of my admin ftp account. Afterwards the membership code believed that I was logged in (with the user name [MachineName]\[FTPUserName]), causing a lot of new bugs (because this account couldn't be associated with an user id by my own code).
While all I had to do was to fix the first bug, I really would like to know why the membership code of asp.net was able to use the FTP credentials for a login and why it tried to do so in the first place.
Additional information: This bug didn't occurred when I debugged the program on my personal computer, only on the web server where I published it.
Please ask if more information is required.
I think it could be because some statics files, images for example, are in a folder that is not visible for everyone. Does the IIS_IUSRS have read access on the directory server (in properties/security of the folder)? Do you have custom rules in your FTP setup that protect some files? That should explain why it works on your computer but not online. It's more an IIS setup problem then a MVC problem.
I am working on an old Classic ASP website and there is a directory that contents a handful of PDF documents. Is there a way to stop a user from accessing said pdf documents via a direct link (www.example.com/example.pdf) until they login? If so, how would I go about it?
Does ASP have the build in Membership provider which controls access with a couple lines in a web.config in that directory
http://msdn.microsoft.com/en-us/library/yh26yfzy%28v=vs.80%29.aspx
The following article from Microsft explains how to protect access to certain pages using classic ASP.
How To Use Simple ASP Code to Password Protect Your ASP Pages
Here are a couple of additional links, that are both for ASP.NET, but perhaps you can use the same ideas in classic ASP.
Thread: How do I password protect a sub folder of my website, to deny anonymous access?
Here's a similar article: Protecting Folders with Forms Authentication
I presume your web site already have a login infrastructure.
If not you should add it as first thing | http://www.evolt.org/node/28652.
Then create page and put it in the place of the resource you want to protect. E.g. replace http://youwebsite.com/dir1/dir2/file.pdf with http://yourwebsite.com/dir1/dir2/getfilepdf.asp.
In your new script check if the user have done log on, if not send it back to log on page.
If the user is correctly authenticated, read the file and return it to browser with Response.BinaryWrite.
The web is full of samples. Read this | http://support.microsoft.com/kb/307603.
Password protection on the page listing your documents will not prevent direct access to the documents. For example if your documents are listed by folder view or are linked from any web page then every search engine and spider on the planet already knows the document's location in your site. So here's what you can do...
Start by moving the document folder to below root level, then use FileSystemObject to deliver the document. For documents over 2-4 Mb you should deliver them in "chunks".
Now you can add a condition to your download script to verify the user's log-in status or redirect to log-in. Your comment link will now look something like:
http://somesite.com/load-pdf.asp?id=mydocuent.pdf
If you were providing a list of documents by folder view you can still do that using FileSystemObject.
I am looking for a way to get the identity of the process which executes a *.vbs file or a *.asp file. How to write code to determine the process identity from within the file itself? Suppose I execute the file, it should output the full name of the user (i.e. domain\username).
I've taken a look at this code, but it lists all the processes and then displays the identity of each process. I don't think this is appropriate: if I use the same code in an asp file and executed it via a browser request, I am thinking it would be hard to determine which process is exactly executing it.
EDIT: hope this should explain my requirement better -> what if I wanted my script file asp/vbscript to be run by a particular user and not anyone else?!
Think this might solve at least part of your problem. This is taken from an answer on Google Answers:
You can grant them access to the site based on their Windows log-in
simply by unenabling Anonymous access and enabling Integrated Windows
authentication in the IIS console -> Anonymous access and
authentication control -> Edit... dialogue.
Once authenticated with Integrated Windows, you can get their username
through Request.ServerVariables("LOGON_USER").
I have a system that allows the users to download some files, the user needs to login first and then he is autorized or not to download. The download page is Download.aspx?FileId=42 and the code within this page opens the file and keeps sending small chunks to the user. We made this because we needed to guarantee that only authorized users could download.
We recently moved this system to IIS7 and it is working properly, but I don't like the idea of having a custom c# code sending the chunks to the client, so I would like to know if there is a way of when a request to file.zip is made, a custom code is executed to authorize or not, and if it is authorized, I just tell IIS7 to proceed the download instead of running the code inside Download.aspx.
Is this possible?
Thanks!
Do a redirect to the zip file. Hide the zip file in a obscure location with non-regular naming. "Security through obscurity."
IIS7 has authorization that uses Forms or Windows authentication for all file types - if it's running in integrated pipeline mode. The syntax is just like that for ASP.NET applications, but it's in a different place in web.config, <system.web>. The rules can also be added using the IIS7 admin interface. There are a couple of differences, IIS7 URL authorization evaluates rules from the parent down and deny rules take precedence.
I have an application that uses Forms Authentication to authenticate one type of user. There is a section in this application that needs to be authenticated for another type of user using a different table in the database. The problem happens if the second type of user's session times out, she is taken to the login page defined in the Forms Authentication section of the main Web.Config instead of the login page for the second type of user. I am looking for solutions to this problem. One idea is to create an application in IIS for the section and create a Web.Config for the folder and add another Forms Authentication section. In my experiments, it seems this doesn't work. Am I missing something obvious? Any insights?
IIRC, the authentication works per folder. So you should be able to do it if all of the pages that require the 2nd type of authentication live in a specific sub-folder with it's own config.
Not 100% sure on this, though, so if someone more knowledgeable can contradict me I'll just delete the response.
You may need to double check me on the syntax, but the top level web.config can have any number of tags.
<location>...</location>
Inside you can specify separate config parameters for whatever folder/file you want. Look here for a reference.
EDIT: Apoligies, I neglected to format the code properly
You cannot have an <authentication> section inside of a <location> tag, so you must have the subfolder set up as an IIS (and ASP.NET) application of it's own. So, you should be able to run the subsection on it's own.
I think 500.19 is the "can't read or parse web.config" error - does it have details? You may need to turn on remote errors (or check Event Viewer) to see them. If you're still having issues, post a snippet of web.config.
As an aside - I've never been a fan of nested apps, and would probably prefer having your normal Login.aspx page handle it either with as a MemberOf or perhaps redirecting to a SpecialUserLogin.aspx or something. Nested apps are a PITA to setup and test, IME (for instance - I don't think you can even get it working under Cassini - though you can do 2 separate projects for it, and combine when you deploy).
Yes you can. The Web.config files have a tree-like inheriting arhitecture with override capabilities. Meaning you can modify the settings inside a sub-folder by placing a web.config file there and specifying different configuration settings.
The way I understand this problem, you have two solutions and the first is to look at Roles and the whole Provider Model would be a great place to start. Otherwise, the best bet would be to separate the application into two parts, breaking out the second user type area and then including it back into the main project via a Virtual Directory. Just remember that Virtual Directories inherit their permissions from the parent directories web.config, so you will need to use the <Location>tags to remove authentication for the virtual directory and then within the virtual directories web.config define your new forms authentication. This works well if you need Windows Authentication (NTLM) under Forms Authentication.