FSO permissions for an Intranet 2

[ryandoah]

Hi all,

I'm trying to use the file Scripting Object on my Intranet. After some permissions problems, I set the permissions to everyone/everything on the appropriate directories, but am still getting permission denied errors when I try to run a CreateTextFile function.

I've got the FSO running on two different, other Internet sites(on different machines/IIS's) and it seems to work fine. I know that for the Internets, which are set to allow anonymous traffic, IIS uses the IUSR_<machinename> log in name to authenticate.

Knowing that the Intranet uses Windows Integrated Authentication for the Intranet site by authenticating user network log in names, I have also explicitly given modify permissions to myself(my login), yet still get permission denied errors.

I've also added myself, explicitly as an Operator in IIS.

Anyone have any idea what I'm doing wrong? The answer to this seems pretty simple, since I'm authenticating with domain user names and passwords and am able to give those user name explicit permissions, but can't seem to get it right.

Thank you,

ryandoah

 

[DotNetGnat]

please take a look at this link...

i guess it should answer your question...

http://www.15seconds.com/issue/000816.htm

-DNG

 

[DotNetGnat]

read the permissions part of the section on the link carefully...

Permissions


Now that we've covered the basics, we should discuss permissions. The FSO runs in the user account that created it. In other words, if someone accesses your page from the internet, then the internet account created the FSO. If you are logged onto your computer as the administrator and you access the page, then the administrator account created it. This is very important, because certain accounts have certain permissions, and the FSO requires a lot of permissions in order to function fully. 

The internet account (IUSER_MachineName, where MachineName is the name of the server) generally has only reading privileges. That means that users will never be able to write to the guestbook file. There are, however, several options to skirt around this issue. 

The first, and more difficult, would be to require the user to log on to the server before they fill out the guestbook. However, the point of a guestbook is to get information from anonymous users, and to log users on, we'd have to know who they are, so we'll skip this option and move on. 

The second is to create a directory or file that allows the IUSER_MachineName account writing privileges. This can open up some potential security holes, because anyone who knows the proper directory and some savvy web skills can write stuff to your server. This is a big no-no. So you want to make sure you place the writeable directory in a nice and hidden spot, and possibly place it outside of the web directory structure (i.e. in Windows, place it in a directory that is outside the inetpub directory)

-DNG

 

[ryandoah]

Ok, I agree with that section, but it raises a few questions.

Since I am trying to do this on an intranet, and I'm authenticate the user, according to their NT domain login name, does IIS create the fso object as the NT login name or as the IUSR_<name>?

The passage says:

If you are logged onto your computer as the administrator and you access the page, then the administrator account created it.

So I would assume that if I were logging in through the Intranet, thus authenticating with my NT login name(I checked the serverVariable.Remote_User which returns my domain login name), then the object would be created with this name. I have full permissions on the entire directory structure, and am listed as a domain administrator through the domain.

 

[Gorkem]

Hey Ryan,

Have you checked to make sure that the folder allows WRITE access in IIS? This is always usally overlooked when setting the persmissions for FSO to write into a folder through IIS.

Cheers,

G.



Xedia Media Solutions

http://www.xedia.ca

-----------------------------
Components/Tools/Forums/Software/Web Services

 

[ryandoah]

I haven't done that. I've been dealing with the NTFS permissions up until now.

I'll go check that.

 

[ryandoah]

Nothing new to find in there. I've already got the IIS set to allow read and write. The directory I am trying to get this working in is set up as a virtually directory, not sure if that has anything to do with it, though I doubt it.

This is really strange.

 

[Gorkem]

Did you check the read/write for the entire site or just the virtual folder.. sometimes the virtual folder will have it's own rights and will not carry the default settings for the main site.

Cheers,

G.



Oxigen - Next generation business solutions

http://www.oxigen.ca

-----------------------------
Components/Tools/Forums/Software/Web Services

 

[ryandoah]

Yeah, I checked both, both are set to read & write.

The NTFS on the directories themselves are currently set to Everyone(modify). I also tried to explicitly define the individual NT logon name permissions with no luck either.

Everything seems like it should be, but still get the permission denied errors. I've spent most of the morning on MSDN, everything I read involving the FSO and FSO permission has to deal with accessing it from an Internet though the IUSR_<name>.

 

[Gorkem]

can you post your code here? There may be something that we're missing in there somewhere.

Cheers,

G.


Oxigen - Next generation business solutions

http://www.oxigen.ca

-----------------------------
Components/Tools/Forums/Software/Web Services

 

[DotNetGnat]

Ryan,

I read this online and thought may be useful...as far as i see i think you have done everything correct...post the relevant code as Gorkem suggested...

1. the FileSystemObject's purpose is to allow an ASP page (or VB program, or WSH file) to have access to the machine's file system. Since your ASP pages reside and are executed on the web server, when using FSO to access the file system, you are accessing the web server's file system. You cannot access the client's file system using the FileSystemObject in your ASP code. 

2. In Windows NT, there are three types of permissions: Read, Write, and Full Access. Whenever an ASP page attempts to execute some file system command using FSO, the anonymous web user ID is used: IUSR_machinename (i.e., if your webserver is named Bob, the user ID is IUSR_Bob). If IUSR_machinename doesn't have permissions to Read for a particular directory, you cannot use FSO to read the contents of a file in that directory through an ASP page. If IUSR_machinename doesn't have permissions to Write for a particular directory, you cannot use FSO to write a file to that directory through an ASP page. If IUSR_machinename doesn't have Full Access permissions for a particular directory, you cannot use FSO to delete or move a file from that directory through an ASP page.

-DNG

 

[ryandoah]

Upon your request for the code, it made me think to reexamine the code.

At this point, I must disclaimer that I did NOT write the original code for this script. It was written by one of my supervisors, who's job description doesn't entail coding, but had code some COBAL back in the day, so thinks he's Mr.Code.

I've had problems with this guys "work" in the past, in this scenario, as usual, he opted not to use the option explicit directive in his asp code, so, of course, IIS wasn't trying to varify his variables.

One other problem that I have consistantly had with his code is the fact that he uses cryptic variable name, which further obfusticates the code.

This time it was a combination of both that was the problem.

His original code:

dim fso, f1
Set fso =server.CreateObject("Scripting.FileSystemObject")
Set f1= fso.CreateTextFile("testfile.txt", TRUE)
fl.writeline(strTop + strTitle + strBody + strBottom)
fl.close

By adding the option explicit directive, and rewriting just about the whole page so I could actually read it and get all the variable defined properly, I found that after the second use of the variable f1 (eff-one) he had somehow started using, instead, fl (eff-ell).

I feel kind of like a jakass, letting this type of error slip past me. This has taught me two very important lessons; 1) Never trust that another person's code is correct, 2) Quality control is essential from the bottom up.

Sheez. I wish the guy would just do his job and let others do likewise. Thank you all for the help, and I apologize for the goose chase. Gorkem, Thank you for reminding me to relook the code.

ryandoah

 

[ryandoah]

what I did to fix this problem that has plagued me for days?

dim fso, createFile
Set fso = server.CreateObject("Scripting.FileSystemObject")
Set createFile = fso.CreateTextFile("testfile.txt", TRUE)
createFile.writeLine(strTop + strTitle + strBody + strBottom)
createFile.close

I changed the ambigous variable name f1/fl to createFile.

 

[DotNetGnat]

its always difficult to modify the code written by someone else...

but anyways...glad that everything is working fine for you...

-DNG

 

[ryandoah]

Also, one last thing. The file name reference for the CreateTextFile method should be a fully qualified path.