I have a .NET a web app that i built for files processing .I am using IIS 7 anonymous user authentication , i also did not require the users to log in, so pretty much any user who has access to the intranet can access the web app.
The users said when two of them try to run their files on app at the same time they receive an error( did not specify it).
My question is :
If i use anonymous authentication is it by default every user will have his\her own session while accessing the app?
Yes, by default every user will have their own session. And anonymous authentication is the default scheme for the web. It is unlikely that any web server, by default, would only allow 1 anonymous user at a time.
Most likely, if your app is doing file processing, you may be dealing with file locks and not an issue with IIS. You want to make sure that your code is written so that, if two or more people access it simultaneously, they can not request to same file. Also, you need to make sure that you are properly closing any file streams you open, even in the case of exceptions. Without seeing the code in question, it would be difficult to impossible to give more specific guidance, but hopefully this will help point you in the correct direction.
Install Elmah to get error report of ypur app!
Related
Is anybody knows how to share cookies between 2 windows users?
I have a Windows 10, where have 2 users: one is admin and second is operator.
Admin is logged in into the system and then goes to the web site, where setup some config. In this config we have some specific value which should be store locally in machine and operator shouldn't know nothing about it. So he is set some kookie { someKey: someValue } and then log out from Windows.
After this operator log in into Windows and open the same website and he should have access to this cookie { someKey: someValue }.
I search around we and found nothing about it. Found only solutions about save to file system, send via tokens and save MAC address with a value into DB. But this is not suitable for me. I know that share cookies and store locally isn't secure, but need to implement that feature.
Web project based on chrome browser, asp.net mvc, angularjs and ms sql for db storage. Is anybody can help me with this issue about cookies?
There is no way to do this. First, every browser has its own way to store and retrieve cookies. It is impossible to write something that will work for any platform and any version.
Second, there is security. You can't just copy some files and expect this to work. Browser developers aren't stupid to leave such a big security loophole in their software.
You are mixing Windows applications with full control over the system with a web application that only resides within the browser. You should find a better way. You could use a certificate installed on the machine to validate the user, but it seems to me there are better options, like simply logging in, etc.
Cookies are a browser component that all major browsers locate in user specific directories. if you could change it to HTML5 storage API and you could setup the storage to a folder both users have access (dunno about this). You could have client side shared data. Most probably, you could not. And certainly not using cookies.
Disclaimer: I havent used storage API
Edit: Just checked. Storage API does store the data un user specific folders, so cannot use it either.
"In practice, "client-side storage" means data is passed to the browser's storage API, which saves it on the local device in the same area as it stores other user-specific information, e.g. preferences and cache. Beyond saving data, the APIs let you retrieve data, and in some cases, perform searches and batch manipulations." Source: https://www.html5rocks.com/en/tutorials/offline/storage/
I have a tough question here and I would like to tap the wisdom of the masses to ensure that I am approaching this issue in the most efficient way possible.
Goal: Move 78 web applications (all configured to be an IIS application under a root website) from a Windows Server 2003 box to a 2012 box with as little coding as possible. The 2012 box has a different subdomain "xxx2.blah.com" and the 03 server is mapped to a "xxx.blah.com" server. In short, the user bookmarks won't work once we migrate so we want to write a redirection utility to assist getting the users to the new xxx2.blach.com location without them noticing.
Current State:It is important to note that each application under the root website in IIS6 is configured to run under its own, and sometimes shared, app pools. Some of the applications have querystring values appended to the end of the .NET request that we want to retain because it affects the UI and other business logic already coded.
We were thinking of removing the files within each application to force IIS to return a 404. Once the 404 occurs, we were wanting to run our custom utility to lookup what the equivalent URL is. Since the 404 is an "error" by all intents and purposes, we were thinking that we could "handle" the error like this (ASP.NET 2.0 : Best Practice for writing Error Page)
Is it possible to write that code once, add the logic to the global.asax file in the root website, and then somehow instruct each web application under that root site to execute the code in the parent site? I know they each run under their own app pool and that may mean that we cannot pass execution off onto another application easily but I could be wrong. In addition, we are hoping to not have to copy/paste code 78 times. Any general "best practices" or advice would be greatly appreciated. Also, adjusting it on the network is not an option as the old xxx.blah.com is on a completely different network than the new xxx2.blah.com network.
#Carl
Thank you very much. I initially missed that those variables were available to me for this purpose! The final solution for me was to set the "Redirect To" textbox to "http://xxx2.blah.com$V?UpdateNote=true&$P". This enables the redirection to occur with both the path and querystring name/value pairs in tact and also allowed me to append my own value so that the application could detect it and display a "This page has moved" message to the user.
Thank you Carl! You da man.
This is almost identical to this question asked by another user, and is the sequel to a question I asked previously.
Basically, my company recently bought Tidal Scheduler. We need to launch jobs ad hoc from other process, e.g.: BizTalk, .NET web apps, etc. Our plan was to wrap a .net web service around the C++ API. That is apparently going away version.next, so we are instead trying to wrap a .net web service around their command line interface.
The client requires Active Directory authentication. Using pretty much every method below for impersonation we have been unable to successfully call the CLI from our .net web service. From what I read in the question linked above, we are trying to impersonate a user with more rights than the ASPNET account, and this causes a security hole.
Is there a better way to do this? Is there a way to make it work with the road we have already traveled? Any help is appreciated, we have sunk way to much time into this.
Side note: we did make this happen using PsExec, but at this point it's such a huge hack-around (it's a big enough hack-around as it is) that we would very much prefer not to use this in our environment.
One possible method would be to run the web service in an App Pool that has the credentials of the user you need to impersonate. (This is assuming the authentication is the result of trying the operation and failing as the account running the current web service....if it requires authentication even when running as the user you're impersonating, you're out of luck.)
The impersonated user will need to be a member of the IIS_WPG group on the box the web service is running under. It may also need a few local permissions. Just make sure the user you are impersonating as very limited rights on the box itself.
Perhaps what you need is a windows service that has your credentials. Then your web service can call your WIndows Service to execute whatever it is you want to do. A Windows Service is a project template in Visual Studio and the docs on MSDN are very straightforward.
We are rolling out a site for a client using IIS tomorrow.
I am to take the site down to the general public (Sorry, we are updating message) and allow the client to test over the weekend after we perform the upgrade.
If it is successful, I open it to everbody - if not, I rollback.
What is the easiest way to put a "We're not open" sign for the general public, but leave the rest open to testers?
Redirect via IIS. Create a new website in IIS and put your "Sorry updating" message in the Default.aspx. Then switch ports between the real site (will go from 80, to something else (6666)) and the 'maintenance' site (set on 80).
Then tell your testers to go to yoursite.com:6666.
Then switch the real site back to 80 after taking down the 'maintenance' site.
I thought it would be worthwhile to mention ASP.NET 2.0+'s "app offline" feature. (Yes, I realize the questioner wants to leave the app up for testing, but I'm writing this for later readers who might come here with different needs).
If you really want to take the application offline for everyone (for instance to do server maintenance) there is a very simple option. All you have to do in ASP.NET 2.0 and higher is put a file with this name:
app_offline.htm
...in the root directory of your ASP.NET application. Put an appropriate "sorry come back later" message in there. That's it. The ASP.NET runtime does the rest.
Details on Scott Guthrie's blog.
Require that testers login. You can even hide the login page so that you need a direct link to even see it. Then, for all people not logged in, redirect to the page that displays your message.
Fire up another "site" in IIS which will catch your host-header for your primary site. Use either a custom 307/503/404 page that has "we're down for maintainance" or use some sort of URL-rewrite to redirect people to your single static file.
switch host-header-binding on your real site to something else, like dev.domain.com or testing.domain.com that your developers use.
Or, block by IP, and have your custom "Not authorized" page tell visitors that your down to maintainance.
You have several options.
Some methods that I've used before:
Windows authentication and/or separate subdomains for client to test.
Disable anonymous website access in IIS and give your client a username/password combo to test the website.
Disable default document in IIS and give your client an absolute URL to the main index file.
We tend to have a log in page and an include file across all pages in the site (usually the DB Connection as it's included in all files) that checks for a valid logged in session. If you've not logged in you get a message saying the site's down for maintainance
Running into a problem where on certain servers we get an error that the directory name is invalid when using Path.GetTempFileName. Further investigation shows that it is trying to write a file to c:\Documents and Setting\computername\aspnet\local settings\temp (found by using Path.GetTempPath). This folder exists so I'm assuming this must be a permissions issue with respect to the asp.net account.
I've been told by some that Path.GetTempFileName should be pointing to C:\Windows\Microsoft.NET\Framework\v2.0.50727\temporaryasp.net files.
I've also been told that this problem may be due to the order in which IIS and .NET where installed on the server. I've done the typical 'aspnet_regiis -i' and checked security on the folders etc. At this point I'm stuck.
Can anyone shed some light on this?
**Update:**Turns out that providing 'IUSR_ComputerName' access to the folder does the trick. Is that the correct procedure? I don't seem to recall doing that in the past, and obviously, want to follow best practices to maintain security. This is, after all, part of a file upload process.
This is probably a combination of impersonation and a mismatch of different authentication methods occurring.
There are many pieces; I'll try to go over them one by one.
Impersonation is a technique to "temporarily" switch the user account under which a thread is running. Essentially, the thread briefly gains the same rights and access -- no more, no less -- as the account that is being impersonated. As soon as the thread is done creating the web page, it "reverts" back to the original account and gets ready for the next call. This technique is used to access resources that only the user logged into your web site has access to. Hold onto the concept for a minute.
Now, by default ASP.NET runs a web site under a local account called ASPNET. Again, by default, only the ASPNET account and members of the Administrators group can write to that folder. Your temporary folder is under that account's purview. This is the second piece of the puzzle.
Impersonation doesn't happen on its own. It needs to be turn on intentionally in your web.config.
<identity impersonate="true" />
If the setting is missing or set to false, your code will execute pure and simply under the ASPNET account mentioned above. Given your error message, I'm positive that you have impersonation=true. There is nothing wrong with that! Impersonation has advantages and disadvantages that go beyond this discussion.
There is one question left: when you use impersonation, which account gets impersonated?
Unless you specify the account in the web.config (full syntax of the identity element here), the account impersonated is the one that the IIS handed over to ASP.NET. And that depends on how the user has authenticated (or not) into the site. That is your third and final piece.
The IUSR_ComputerName account is a low-rights account created by IIS. By default, this account is the account under which a web call runs if the user could not be authenticated. That is, the user comes in as an "anonymous".
In summary, this is what is happening to you:
Your user is trying to access the web site, and IIS could not authenticate the person for some reason. Because Anonymous access is ON, (or you would not see IUSRComputerName accessing the temp folder), IIS allows the user in anyway, but as a generic user. Your ASP.NET code runs and impersonates this generic IUSR___ComputerName "guest" account; only now the code doesn't have access to the things that the ASPNET account had access to, including its own temporary folder.
Granting IUSR_ComputerName WRITE access to the folder makes your symptoms go away.
But that just the symptoms. You need to review why is the person coming as "Anonymous/Guest"?
There are two likely scenarios:
a) You intended to use IIS for authentication, but the authentication settings in IIS for some of your servers are wrong.
In that case, you need to disable Anonymous access on those servers so that the usual authentication mechanisms take place. Note that you might still need to grant to your users access to that temporary folder, or use another folder instead, one to which your users already have access.
I have worked with this scenario many times, and quite frankly it gives you less headaches to forgo the Temp folder; create a dedicated folder in the server, set the proper permissions, and set its location in web.config.
b) You didn't want to authenticate people anyway, or you wanted to use ASP.NET Forms Authentication (which uses IIS's Anonymous access to bypass checks in IIS and lets ASP.NET handle the authentication directly)
This case is a bit more complicated.
You should go to IIS and disable all forms of authentication other than "Anonymous Access". Note that you can't do that in the developer's box, because the debugger needs Integrated Authentication to be enabled. So your debugging box will behave a bit different than the real server; just be aware of that.
Then, you need to decide whether you should turn impersonation OFF, or conversely, to specify the account to impersonate in the web.config. Do the first if your web server doesn't need outside resources (like a database). Do the latter if your web site does need to run under an account that has access to a database (or some other outside resource).
You have two more alternatives to specify the account to impersonate. One, you could go to IIS and change the "anonymous" account to be one with access to the resource instead of the one IIS manages for you. The second alternative is to stash the account and password encrypted in the registry. That step is a bit complicated and also goes beyond the scope of this discussion.
Good luck!
I encountered this error while diagnosing a console app that was writing in temp files. In one of my test iterations I purged all the files/directories in temp for a 'clean-slate' run. I resolved this self inflicted issue by logging out and back in again.
Could be because IIS_WPG does not have access to a temp folder. If you think it is a permission issue, run a Procmon on asp.net worker process and check for AccessDenied errors.
I was having the same problem with one of my ASP.Net applications. I was getting Path.GetTempPath() but it was throwing an exception of:
"Could not write to file "C:\Windows\Temp\somefilename", exception: Access to the path "C:\Windows\Temp\somefilename" is denied."
I tried a few suggestions on this page, but nothing helped.
In the end, I went onto the web server (IIS server) and changed permissions on the server's "C:\Windows\Temp" directory to give the "Everyone" user full read-write permissions.
And then, finally, the exception went away, and my users could download files from the application. Phew!
You can use Path.GetTempPath() to find out which directory to which it's trying to write.