Re: Script access - IIS 6
From: David Wang [Msft] (someone_at_online.microsoft.com)
Date: 08/05/03
- Next message: David Wang [Msft]: "Re: W2K IIS under attack"
- Previous message: Angel: "Re: Intranet Site Auto Login"
- In reply to: Mark Hildreth: "Re: Script access - IIS 6"
- Next in thread: Mark Hildreth: "Re: Script access - IIS 6"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 5 Aug 2003 13:20:53 -0700
That's ok. There's a bunch of terms that refer to the same thing; sometimes
the documentation folks change terminology and create new words for us.
Scripts is one of those instances:
A Script is a web-accessible resource that is executed by something else to
return content (versus executable, which can directly be executed to return
content, like a CGI EXE or an ISAPI DLL). Hence, your Python file is a
Script, and the Python interpreter EXE is the ScriptEngine that executes the
Python file to produce a response. The ScriptEngine can be a CGI EXE (like
your Python) or ISAPI DLL (like ASP/ASP.Net).
IIS chose file extension as a mean to associate resource type and Script
Engine, hence I refer to it as a ScriptMap (or Script Mapping). This
mapping is also called Application Mapping by the documentation (who seem to
do a search/replace of "Script" with "Application").
-- //David This posting is provided "AS IS" with no warranties, and confers no rights. // "Mark Hildreth" <mhildreth@sbcglobal.net> wrote in message news:%23f4R6h3WDHA.652@tk2msftngp13.phx.gbl... I am confused by your use of ScriptMap and ScriptMap Engine. I can find no occurance of these terms in the knowledgebase. What are you referring to here? Thanks... Mark "David Wang [Msft]" <someone@online.microsoft.com> wrote in message news:ecQYtAzWDHA.1492@TK2MSFTNGP12.phx.gbl... > If you reset ACLs to allow anonymous access and everything works (even for > the "Authenticated") case, then I question whether you are actually > authenticating. > > I can note that the default web directories that IIS sets up serves as an > illustration of what would work. I could not reproduce your claims using > ACLs from those default web directories. You should see whether it works > for you as well before touching ACLs. > > The basics of ACLs come down to this: > 1. The Resource (like the script itself) and the ScriptMap Engine (and > associated resources) must be accessible to the remote authenticated user > 2. The remote authenticated user is the configured Anonymous User (default > is IUSR) for anonymous and the logged in user for any other authentication > protocol. > 3. IIS_WPG should have list ACL on the resource to be able to cache it. On > a DC, where IIS_WPG is not allowed, the resource must be list ACL'd to > individual members of the IIS_WPG group. > > In the end, you just match the ACLs on the resources with the remote > authenticated users that need access.. You should see at least the above > basics if you look at \inetpub\wwwroot. > > -- > //David > This posting is provided "AS IS" with no warranties, and confers no rights. > // > "Mark Hildreth" <mhildreth@sbcglobal.net> wrote in message > news:uyIayTuWDHA.2444@tk2msftngp13.phx.gbl... > I have reset the ACL to allow anonymous access and everything works. What > next? > > "David Wang [Msft]" <someone@online.microsoft.com> wrote in message > news:%23OGnXIKWDHA.2056@TK2MSFTNGP11.phx.gbl... > > If you make requests of the form > > http://cvstest/viewcvs/viewcvs.cgi/modulename , does that work? > > > > Namely, does this CGI depend on PATH_INFO or not? I am suspecting it > does. > > > > I tried to duplicate it by doing the following: > > 1. I set a Scriptmap of .cgi to C:\Inetpub\wwwroot\MyCGI.EXE (avoiding > > any ACL issues) > > 2. I set DefaultDoc on / to be test.cgi > > 3. I created a file test.cgi so that DefaultDoc works > > > > I made a request to http://localhost/ and http:/localhost/test.cgi under > > anonymous, basic, and NTLM, and all passed (they invoked MyCGI.EXE to > return > > content). > > > > I am using default ACLs, default AppPoolId of Network Service. > > > > I do not immediately know what is wrong in your scenario, but if you can > get > > it working in the default case, we can work on lockdown. > > > > I believe the Authentication issue with NTLM is separate from the "Bad > > Headers" issue, so let's take it one at a time. Let's get the files > working > > to not return "Bad Headers" first. NTLM is a connection-based protocol, > so > > I want to ask you whether the CGI works with keep-alive correctly or not. > > > > -- > > //David > > This posting is provided "AS IS" with no warranties, and confers no > rights. > > // > > "Mark Hildreth" <mhildreth@sbcglobal.net> wrote in message > > news:uMxwr4DWDHA.2316@TK2MSFTNGP09.phx.gbl... > > I have used Basic and Windows Integrated Authentication. They behave > > differently. They both behave the same for the originally described > problem. > > After using the http://cvstest/viewcvs/ URL and successfully > > authenticating, there are links in the format > > http://cvstest/viewcvs/viewcvs.cgi/modulename. If I've authenticated with > > Basic, these links work, with Integrated they do not. > > > > By the way, viewcvs is a virtual directory on the same machine. > > > > App Pool Identity is Network Service. I've tried local system as well. > > > > ACL is Local Administrators Group, CVS Users Group and SYSTEM all have > full > > control. > > > > Do know the answer to "How is cgi scriptmapped?" > > > > viewcvs.cgi is the only default document. > > > > > I am therefore thinking of what would cause the IIS resolution and > > > re-execution to fail, and I'm looking at the request up to the > > ScriptEngine. > > > > The redirect case is the one that works, it's the explicit URL > > http://cvstest/viewcvs/viewcvs.cgi that does not. > > > > Thanks... > > > > Mark > > > > > > "David Wang [Msft]" <someone@online.microsoft.com> wrote in message > > news:es3GNOBWDHA.212@TK2MSFTNGP12.phx.gbl... > > > How did you configure authenticated access (what sort of > authentication). > > > > > > Are you running with a custom AppPoolIdentity. > > > > > > What are the ACLs on the accessed resources. > > > > > > How is .cgi scriptmapped (does it have ScriptEngine/File not Found > > options). > > > > > > If you configure viewcvs.cgi as a DefaultDoc (is it the only one?), both > > > URLs are the same. The first one will cause IIS to send a courtesy > > redirect > > > to http://cvstest/viewcvs/ back to the client, and when the client > > requests > > > this URL behind-the-scenes, IIS would resolve / to /viewcvs.cgi and > > execute > > > http://cvstest/viewcvs/viewcvs.cgi using the ScriptEngine configured for > > the > > > .cgi Scriptmap -- the same as if you made a direct request to it. > > > > > > I am therefore thinking of what would cause the IIS resolution and > > > re-execution to fail, and I'm looking at the request up to the > > ScriptEngine. > > > > > > -- > > > //David > > > This posting is provided "AS IS" with no warranties, and confers no > > rights. > > > // > > > "Mark Hildreth" <mhildreth@sbcglobal.net> wrote in message > > > news:en4FMI$VDHA.2248@TK2MSFTNGP10.phx.gbl... > > > I am trying to execute a python script on IIS 6 as follows: > > > > > > Anonymous access > > > http://cvstest/viewcvs and http://cvstest/viewcvs/viewcvs.cgi > > > Both of the above work. I have made viewcvs.cgi a default page for the > > > directory. > > > > > > Authenticated access: > > > Removed anonymous access, added ACL for user group. viewcvs.cgi remains > a > > > default page for the directory. > > > http://cvstest/viewcvs presents authentication dialog and works. > > > http://cvstest/viewcvs/viewcvs.cgi does not present authentication > dialog. > > > Returns: > > > > > > ******************************** > > > CGI Error > > > The specified CGI application misbehaved by not returning a complete set > > of > > > HTTP headers. > > > > > > ********************************* > > > > > > The script is unchanged in all cases. Only the NTFS permissions are > > changed > > > > > > -- Thanks in advance.... > > > ------------------------------------------ > > > Mark Hildreth > > > IT Response, Inc. > > > 205 Rustic Place > > > San Ramon, CA 94583 > > > mark@ITResponse.com > > > (925) 828-7650 > > > (925) 699-6800 (cell) > > > > > > > > > > > > > > > > > > > >
- Next message: David Wang [Msft]: "Re: W2K IIS under attack"
- Previous message: Angel: "Re: Intranet Site Auto Login"
- In reply to: Mark Hildreth: "Re: Script access - IIS 6"
- Next in thread: Mark Hildreth: "Re: Script access - IIS 6"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
