Handling Multiusers in PHWEB ( the late shift )

[brian_matthewsbrian matthews]

it now seems that we will set up the system to use SSH calls ( Secure SHell 
versions of the rcp, rsh, and rlogin programs ) to execute the script files, 
and we will have web authentification ( along with ssl/HTTPS calls to hide 
passwords ) to get the userid and password.

So hopefully its all in the Unix/webserver configuration so no need to get a 
password specifically by prompting from the PHWeb app after all; or even 
prompt for a userid in our opening PHWeb page, because we can get the userid 
value entered during the web authentication stage from the weblogonid 
function.

Have also taken up the idea of the userid + sysdate + systime record key, 
but it turns out that we only need the userid because a given userid is 
unique and will have the same env variables, which is all we are storing in 
the the record.

Hopefully it will work out this nicely when we start building/testing.

P.S. nice web site Harold :)

Bri


>From: "Joe Boyle" <joeboyle_adt@hotmail.com>
>To: <powerh-l@lists.sowder.com>
>Subject: RE: Handling Multiusers in PHWEB ( the late shift )
>Date: Thu, 4 Nov 2004 17:19:16 -0000
>
>Jon,
>
>
>
>I notice that you specifically mentioned 'encrypted password' and I also
>wondered how wise this was when I saw that the password was being sent, but
>then I see that the call is as below, so presumably it cannot be seen by
>unwanted eyes ( can it ? )
>
>
>
>let t_get_vars_string = "/usr/bin/phwrscripts/get_user_vars.sh " + f_userid
>+ " " + f_passwd
>
>run command t_get_vars_string
>
>
>
>As for the file/record update, I would go for a key based on the userid +
>ascii(sysdate,8) + ascii(systime,8), set before the script was called from
>the web page ( also stored in a temp for record retrieval ) and sent as a
>third parameter; having passwords as a key segment is probably unwise.
>
>Regards, Joe.
>
>   _____
>
>From: powerh-l-admin@lists.sowder.com
>[mailto:powerh-l-admin@lists.sowder.com] On Behalf Of Bickel, Jon
>Sent: 04 November 2004 16:38
>To: powerh-l@lists.sowder.com
>Subject: RE: Handling Multiusers in PHWEB ( the late shift )
>
>
>
>Joe,
>
>
>
>You are correct, my solution does only simulate the actual user.  In my
>situation, my only concern was correctly identifying the true user to
>present them with their individual menu - the process owner was not
>relevant.  However, I believe that a large part of my solution would also
>apply to the rlogin approach since the true username and encrypted password
>do get passed from browser to webserver to Unix.
>
>
>
>jb
>
>-----Original Message-----
>From: Joe Boyle [mailto:joeboyle_adt@hotmail.com]
>Sent: Thursday, November 04, 2004 10:11 AM
>To: 'Bickel, Jon'; powerh-l@lists.sowder.com
>Subject: RE: Handling Multiusers in PHWEB ( the late shift )
>
>Hi Jon ( all ),
>
>
>
>from Brian's suggested script I am guessing that he wants to run the 
>process
>actually logged in as the user concerned, which is a solution I would be
>interested in myself.
>
>
>
>I have looked at your email again and your comment below, which suggests
>that your solution only simulates actually being logged in ( which is also
>great if that is what you want :-)
>
>
>
>'The actual logonid of the session is still the web server administrator,
>but the temp space is effectively that of the true userid (and the true
>userid is available as an environmental variable for  all downstream
>processes).'
>
>
>
>I like the rlogin idea and wonder if it isn't possible to put the $2
>variable on the second line, to be picked up by the password request 
>prompt,
>as below ? ( it's a while since I ran a rlogin call and I am assuming that
>there is a password prompt at this point )
>
>
>
>rlogin theserver -l $1
>
>$2
>
>
>
>
>
>Regards, Joe.
>
>
>
>This e-mail and all information contained in it is confidential and may be
>legally privileged. If you are not the intended recipient, your access to
>this e-mail is unauthorized. Any use, dissemination, distribution,
>publication or copying by you of this e-mail or any of the information
>contained within it is prohibited and may be unlawful. Do not open any
>attachments, delete it immediately from your system and notify the sender
>promptly by e-mail that you have done so. The content of this
>
>e-mail and any attachments sent with it may have been altered without the
>consent or knowledge of the author.
>
>
>
>
>

_________________________________________________________________
Want to block unwanted pop-ups? Download the free MSN Toolbar now!  
http://toolbar.msn.co.uk/