RE: [WEB400] User Profiles

["Haas, Matt" <Matt.Haas@xxxxxxxxxxx>]

This is slightly off-topic (at least for this email) but I do want to point out 
a few potential issues with Scott's configuration example.

The first is that ScriptAliasMatch isn't needed to enable CGI and will drag 
down server performance on a busy site since it uses regular expressions. 
ScriptAlias performs much better and unless you're trying to do something like 
get rid of the .pgm extension (which I don't believe Scott's example does), 
ScriptAlias /cgi-bin /QSYS.LIB/LIBCGI.LIB does the same thing.

The second is that doing basic authentication inside of Directory containers is 
guaranteed to cause grief once you start needing to protect Net.Data or Java 
apps with basic authentication or if you need to have a mixture of protected 
and non-protected content in the same directory. The reason is that Directory 
containers operate off of physical paths which means that authentication is all 
or nothing on a directory by directory basis and it just doesn't work well when 
the physical path to a resource is virtualized by it's run time (like with 
Net.Data or Java apps). It's much better to use Location containers to do basic 
authentication since they operate off of the actual URI of the request and not 
the physical location of the resource.

Matt

-----Original Message-----
From: web400@xxxxxxxxxxxxxxxx [mailto:web400@xxxxxxxxxxxxxxxx]
Sent: Tuesday, February 22, 2005 6:31 PM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] User Profiles



> Is there a way to have the user profile of the one utilizing the web 
> interface to carry through to either opening a file or calling a CGI 
> program?

When I started down the road of making GUI interfaces for my RPG programs, 
I immediately decided that it was a priority for each user to run with 
his/her own authority.  I don't run a public web server on my iSeries, the 
web stuff is just an alternative to 5250. I'd never allow all users to log 
on via 5250 using a single user profile, and likewise I won't allow them 
to log on via Web as QTMHHTTP each time.

So, here's how I went abot making sure that users always use their own 
authority. I have the HTTP server (Powered by Apache) set up as follows:

ScriptAliasMatch ^/cgi-bin/(.*) /QSYS.LIB/LIBCGI.LIB/$1
<Directory /QSYS.LIB/LIBCGI.LIB>
    Order Allow,Deny
    Allow From all
    Require valid-user
    PasswdFile %%SYSTEM%%
    AuthType Basic
    AuthName "AS/400 Sign On"
    ProfileToken on
</Directory>

The idea is that when the calling user accesses a /cgi-bin/ URL, the 
browser prompts the user saying "AS/400 Sign On" and asks for a userid and 
password. This userid/password is compared against the system user 
profiles (i.e. the normal userid/password that a 5250 user would have) and 
if valid, a profile token is generated.  This profile token is passed to 
each and every CGI application in the HTTP_AS_AUTH_PROFILETKN
environment variable.

Each time one of my programs starts, it uses this profile token to run 
with the user's authority.  To accomplish that, I wrote a subprocedure in 
a service program that I call at the start of every CGI program.

The srvpgm routine gets the envvar, base64 decodes it, and calls the 
QSYSETPT API to set the job to run with that users authority.

Actually, it's slightly more complex than that. It saves the authority of 
QTMHHTTP into a profile handle so that the authority can be switched back 
when the user is done.  It also does some error handling setup to ensure 
that no matter what bugs might be in my CGI program, it'll always switch 
back to QTMHHTTP.

I also have an entire menu system that I've been writing (also in RPG via 
CGIDEV2) so that each user will have his/her own customized menu at logon, 
etc... this system also uses the userid set by QSYSETPT in order to know 
which user to display the menus for.

Works really well for me.



-- 
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.