RE: Web Server Authentication

Hi Sisavanh,

Thanks a lot, for both answers (the other about cli-java too).

We don't really need direct port connection, but I didn't know it wasn't
recomended for deployment, just wanted to know. Here we normally test in
HTTP connection mode too, but thought that maybe a customer would
like/prefer for some reason the direct port conection method.

Why is it that it's not recomended ? Only because of the Authentication ?
And if you are running in an intranet, and the app has it's own
authentication method ? That recomendation holds ? Are there some other
issues ? Performance ?

Thanks,

Florencia

> -----Mensaje original-----
> De: [email protected] 
> [mailto:[email protected]] En nombre de Sisavanh SENGSAVANH
> Enviado el: Miércoles, 01 de Marzo de 2006 14:52
> Para: [email protected]
> Asunto: Re: [fourjs-users] Web Server Authentication
> 
> 
> Hi again,
> 
> 
> Haven't anwsered your second question.
> 
> >> Regarding my last paragraph of my last email, disregard it. I'm not
> >> trying
> >> to use these variables FGL_WEBSERVER*, when using WinFE 
> (wtk) or GDC for
> >> Windows. What I was saying was that when we first started using 
> >> "REMOTEUSER"
> >> variable (for Web access), it was a "new" variable. But 
> then the "rlogin"
> >> (server for Linux) started using that same name too 
> (that's what I've 
> >> just
> >> found out with all this issue). So it's ok for us to have 
> this "Web Auth"
> >> variables starting with "FGL_WEBSERVER", because that way 
> we know, no 
> >> other
> >> applicacion will "create" new variables starting with 
> "FGL_". Because 
> >> they
> >> are exclusive to FourJ's.
> >>
> >> So, I think that with your answer about FGL_WEBSERVER_REMOTE_USER
> >> being used
> >> by all WebFE clients, should answer my question.
> >>
> >> But I still have 2 doubts :
> >>
> >> 1) is BDS cli-java also on the list ? Because in one paragraph you 
> >> don't list it, but in another you do.
> > 
> > When I talk about any client that uses WebFE for deployment 
> this also
> > concerns BDS cli-java (JFE).
> > The lastest JFE need WebFE to be deployed.
> > I remember older version JFE was installed with an apache 
> and a tomcat 
> > and was not an "extension" of WebFE.
> > 
> >> 2) when you said "The variables are only set if you use a webserver
> >> (cgi or
> >> isapi)", do you mean that if we use "direct port connection" they 
> >> aren't set
> >> ?
> 
> Right. With direct port connection they are not.
> 
> >> And related to this last question, is there a way to set
> >> Authentication on a
> >> Genero Web Client, using "direct port connection" ?
> 
> Direct connection to GWC or GAS is really not recommended in 
> deployment. The authentication is done by the Web Server. The 
> authentication supposes you ask the user login and password. 
> You don't have such mechanism in GWC or GAS. We have a 
> request registered to support authentication (FZ#1522).
> 
> Why do you need a "direct port connection" ?
> 
> 
> Many regards,
> -- 
> ____________________________________________________________
> 
> Sisavanh SENGSAVANH                    European Support Team
> mailto:[email protected]           Phone: +33 (0)3 88 18 61 24
> Four J's Development Tools - Genero, It speaks your language 
> http://www.4js.com 
> 
> >>
> >> Thanks,
> >>
> >> Florencia
> >>
> >>> -----Mensaje original-----
> >>> De: [email protected] 
> [mailto:[email protected]] 
> >>> En nombre de Sisavanh SENGSAVANH Enviado el: Miércoles, 
> 01 de Marzo 
> >>> de 2006 07:19
> >>> Para: [email protected]
> >>> Asunto: Re: [fourjs-users] Web Server Authentication
> >>>
> >>>
> >>> Hi Florencia and Leo,
> >>>
> >>>
> >>>> Ive changed the thread name, because it became "misleading".
> >>>>
> >>>> Thanks for your answer, and confirmation on the variable used by 
> >>>> Genero web clients. But can you tell me where in Genero 
> docs can I 
> >>>> find about FGL_WEBSERVER_REMOTE_USER ? I want to read it 
> again, and 
> >>>> see if I'm not missing anything. When I added that to our
> >>> library, we
> >>>> were just testing, and know we are actually migrating, and
> >>> I want to
> >>>> re-check this.
> >>> Sorry, it was in old documentation 3.20 of WebFE.
> >>> We will add this to the GAS documentation.
> >>>
> >>> [...]
> >>> environment variables transmitted to the CGI application, by 
> >>> prefixing them with FGL_WEBSERVER_. Those environment 
> variables will 
> >>> be set by the Application Server before running the DVM. [...]
> >>>
> >>> Which means REMOTE_USER transmitted by the CGI becomes 
> >>> FGL_WEBSERVER_REMOTE_USER. Any environment variable xxx 
> transmitted 
> >>> to GCI becomes FGL_WEBSERVER_xxx.
> >>>
> >>>> So, as far as Genero Web clients are concerned, I'm done
> >>> for now (but
> >>>> please send me the documentation).
> >>>>
> >>>> But what about BDS ? I'm not sure I understand. Do you mean last 
> >>>> versions of cli-java are still using FGL_AUTHUSER ? No 
> matter what 
> >>>> that mail of April 2nd. 2003 says ? In that case, I 
> could change in 
> >>>> the cjac.cnf, and change REMOTEUSER to
> >>> FGL_WEBSERVER_REMOTE_USER, so I
> >>>> can use that only variable name in my programs ? And what about 
> >>>> cli-html 3.5x ? How is that managed ?
> >>> With any client that uses WebFE (which is BDS Cli-Html
> >>> Client) or GAS or GWC for deployment the FGL_WEBSERVER_ 
> mechanism is
> >>> the same. The variables are only set if you use a 
> webserver (cgi or 
> >>> isapi)
> >>>
> >>> So the products you listed below are using 
> FGL_WEBSERVER_REMOTE_USER
> >>> - BDS Cli-Html Client
> >>> - BDS Cli-Java Client
> >>> - Genero GDC-AX
> >>> - Genero Java Client
> >>> - Genero Web Client
> >>>
> >>>> So this way, if I use FGL_WEBSERVER_REMOTE_USER for all Web 
> >>>> Authenticated users, I can assure no future local
> >>> Authentication (like : SSH, Telnet or
> >>>> Rlogin) will use that variable name, as it starts with 
> FGL_    ;-)
> >>> I don't understand your problem here.
> >>> Do you mean, you want to use direct connection with GDC 
> for example, 
> >>> and this set FGL_WEBSERVER_REMOTE_USER ? If you want to 
> >>> differenciate the connection types through web server or direct 
> >>> connection to DVM, just test if FGL_WEBSERVER_REMOTE_USER 
> is empty 
> >>> or not. If it's empty you are in direct connection so you can use 
> >>> REMOTEUSER instead.
> >>>
> >>> Was this your issue ?
> >>>
> >>> Thanks.
> >>> --
> >>> ____________________________________________________________
> >>>
> >>> Sisavanh SENGSAVANH                    European Support Team
> >>> mailto:[email protected]           Phone: +33 (0)3 88 18 61 24
> >>> Four J's Development Tools - Genero, It speaks your language 
> >>> http://www.4js.com
> >>>> Thanks,
> >>>>
> >>>> Florencia
> >>>>
> >>>>> -----Mensaje original-----
> >>>>> De: [email protected] 
> [mailto:[email protected]]
> >>>>> En nombre de Leo Schubert Enviado el: Martes, 28 de 
> Febrero de 2006 
> >>>>> 14:51
> >>>>> Para: [email protected]
> >>>>> Asunto: Fw: [fourjs-users] Unrespected Password Problem
> >>>>>
> >>>>>
> >>>>> Hi Florencia, I got the following from the Genero HTML
> >>> client team  :
> >>>>>> Florencia is right. All front ends connected on the GAS, the
> >>>>> GWC or the
> >>>>>> WebFE send the user which has been authenticated by 
> the browser,
> >>>>>> through the FGL_WEBSERVER_REMOTE_USER environment variable.
> >>>>> So this affects all Genero products which go thru the 
> Genero GAS. 
> >>>>> I
> >>>>> have no clue, if BDS HTML/java client uses another 
> GAS/App server 
> >>>>> than the Genero one,you should know this better than me...
> >>>>> Seems you need to add a check in your login 
> scripts/programs that 
> >>>>> this variable was additionally set and go ahead depending if 
> >>>>> FGL_AUTHUSER or FGL_WEBSERVER_REMOTE_USER was set. In 
> the WTK case 
> >>>>> you can 'fake' a variable of your choice (export 
> >>>>> FGL_AUTHUSER=`whoami`,or REMOTEUSER or 
> FGL_WEBSERVER_REMOTEUSER) so 
> >>>>> that you don't need to differentiate inside your 
> programs if the 
> >>>>> user was coming from the HTML client or WTK. From my outside 
> >>>>> perspective this seems realtively easy to do, but of course the 
> >>>>> problems appear always in the details...:-) Kind Regards, Leo
> >>>>>
> >>>>>
> >>>>> ----- Original Message -----
> >>>>> From: "Florencia Vitale" <[email protected]>
> >>>>> To: <[email protected]>
> >>>>> Sent: Tuesday, February 28, 2006 3:39 PM
> >>>>> Subject: RE: [fourjs-users] Unrespected Password Problem
> >>>>>
> >>>>>
> >>>>>> Hi Leo,
> >>>>>>
> >>>>>> I don't need REMOTEUSER variable. In fact, the problem is that 
> >>>>>> REMOTEUSER is now being automatically filled in by Linux
> >>>>> (or at least
> >>>>>> by Red Hat's linux) "rlogin" servers, when it 
> previously wasn't.
> >>>>>>
> >>>>>> I'll give you some more background info, so you can 
> understand my 
> >>>>>> problem :
> >>>>>>
> >>>>>> We have an internal function library which identificates
> >>>>> the user name
> >>>>>> that "uses" our app. Due to old issues with LOGNAME 
> variable on 
> >>>>>> different Unix platforms, we decided to identify the user's
> >>>>> name, with
> >>>>>> "SELECT user FROM table_with_one_row". That way we always
> >>>>> got the real
> >>>>>> user name that the "login" identified. With LOGNAME you got
> >>>>> different
> >>>>>> results depending if it came from a "login" or an "su" 
> command. I 
> >>>>>> don't know if this is still an issue, or if it has 
> been unified 
> >>>>>> somehow, but with the SELECT method it worked for years,
> >>> and still
> >>>>>> does.
> >>>>>>
> >>>>>> But, when "Web connections" appeared, with cli-html and
> >>>>> cli-java, we
> >>>>>> needed another way to authenticate REMOTE Users. Why ? Because 
> >>>>>> the USER identified at the server (unix or linux) is always the
> >>>>> same user,
> >>>>>> the one that runs the Application Server (fglhtmld, 
> fglasd, gasd, 
> >>>>>> ...). So, in the case the app is running through an App
> >>> Server, we
> >>>>>> need another way to get the "Authenticated Web Server User".
> >>>>>>
> >>>>>> We could have used our own "login" function, but as we were
> >>>>> also using
> >>>>>> the Web Servers Authentication functions, it seemed rather
> >>>>> clumsy to
> >>>>>> ask for the username twice. So we decided to rely on the
> >>> Web Server
> >>>>>> Authentication.
> >>>>>>
> >>>>>> So in cli-java, the proposed method, that came in the cli-java 
> >>>>>> documentation, and also on the default cjac.cnf, was to use a 
> >>>>>> REMOTEUSER variable instantiated with FGL_AUTHUSER. Why not
> >>>>> directlye
> >>>>>> FGL_AUTHUSER ? I don't know, it was FourJ's 
> recomendation, and we 
> >>>>>> followed. So we added to our custom library a
> >>>>> FGL_GETENV("REMOTEUSER")
> >>>>>> block. If that variable was not null, we used that
> >>>>> username, if not,
> >>>>>> it means that it's not a "remote web user" and so we use
> >>>>> the "SELECT
> >>>>>> user FROM ...." method, which still works for all 
> "local" (ssh, 
> >>>>>> telnet, rlogin, ...) connections.
> >>>>>>
> >>>>>> And now, with Genero, we found out that REMOTEUSER or
> >>>>> FGL_AUTHUSER did
> >>>>>> no longer worked, but that a new environment variable 
> appeared : 
> >>>>>> FGL_WEBSERVER_REMOTE_USER. I couldn't find where that 
> variable is 
> >>>>>> documented. I searched ALL my mails (from the user lists,
> >>>>> from fourj's
> >>>>>> support, etc.) and all the Genero online and downloaded
> >>>>> documentation,
> >>>>>> and could not find it. But I tested it again (as our apps
> >>> in Genero
> >>>>>> are still under migration proccess), and it works.
> >>>>>>
> >>>>>> So, giving all that background I need to know what is the
> >>>>> way to get
> >>>>>> the "remote authenticated user". And if there isn't only
> >>>>> one method, I
> >>>>>> need one for each of the following web clients :
> >>>>>>
> >>>>>> - BDS Cli-Html Client
> >>>>>> - BDS Cli-Java Client
> >>>>>> - Genero GDC-AX
> >>>>>> - Genero Java Client
> >>>>>> - Genero Web Client
> >>>>>>
> >>>>>> As said before, I could not find that in the docs, but I
> >>>>> came across
> >>>>>> the FGL_WEBSERVER_REMOTE_USER for Genero, so somewhere it must 
> >>>>>> be.
> >>>>>>
> >>>>>> But I still need to know about the BDS Cli-HTML and
> >>>>> Cli-Java clients,
> >>>>>> as those environments are still in production. In fact 
> it was on 
> >>>>>> a customer with BDS, with a Linux Server and using "ilogin"
> >>>>> connections
> >>>>>> that all this came up.
> >>>>>>
> >>>>>> For now, as a workarround, we modified our library, and
> >>>>> commented the
> >>>>>> line where we obtained REMOTEUSER variable. But we need to
> >>>>> modify that
> >>>>>> function for good, with the actual definition of "how to
> >>> obtain the
> >>>>>> Remote Authentication Username".
> >>>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> Florencia
> >>>>>>
> >>>>>>> -----Mensaje original-----
> >>>>>>> De: [email protected]
> >>>>> [mailto:[email protected]] En
> >>>>>>> nombre de Leo Schubert Enviado el: Martes, 28 de 
> Febrero de 2006 
> >>>>>>> 08:49
> >>>>>>> Para: [email protected]
> >>>>>>> Asunto: Re: [fourjs-users] Unrespected Password Problem
> >>>>>>>
> >>>>>>>
> >>>>>>> Hi Florencia, I'm afraid I can't follow you 
> completely. To set 
> >>>>>>> the environment variable REMOTEUSER at your server side 
> >>>>>>> correctly with WFE 3.54 you can use the following
> >>> command line for
> >>>>>>> ilogin (in case you want the name of the logged in 
> UNIX user in
> >>>>>>> REMOTEUSER): export REMOTEUSER=`whoami`;@FGL;fglrun 
> yourapp;exit
> >>>>>>>
> >>>>>>> (in case you want the name of the WFE Windows user in
> >>>>>>> REMOTEUSER): export REMOTEUSER=@USR;@FGL;fglrun yourapp;exit
> >>>>>>>
> >>>>>>> because the command line is sent after the rlogin 
> protocol was 
> >>>>>>> successfully handled the rlogin daemon cannot change 
> REMOTEUSER 
> >>>>>>> anymore. But be careful if you set REMOTEUSER in your
> >>> login script,
> >>>>>>> I guess you have something like that: @FGL;myscript.sh;exit
> >>>>>>> and myscript.sh calls fglrun after a bunch of environment
> >>>>>>> settings which might also set
> >>>>>>> REMOTEUSER...
> >>>>>>>
> >>>>>>>> (*1) REMOTEUSER obtains the value of the first USER set in
> >>>>>>> the ilogin
> >>>>>>>> "User" field. If you change it and then login, you keep
> >>>>> getting the
> >>>>>>>> original one. This is the BUG.
> >>>>>>> Does this mean that if you change the name in the "User"
> >>>>> field that
> >>>>>>> you don't log in under the new User name,but as the user
> >>> which was
> >>>>>>> typed in the first time? That would be really a bug . 
> Or is just 
> >>>>>>> REMOTEUSER broken ? Kind Regards, Leo
> >>>>>>>
> >>>>>>>
> >>>>>>> ----- Original Message -----
> >>>>>>> From: "Florencia Vitale" <[email protected]>
> >>>>>>> To: <[email protected]>
> >>>>>>> Sent: Monday, February 27, 2006 6:38 PM
> >>>>>>> Subject: RE: [fourjs-users] Unrespected Password Problem
> >>>>>>>
> >>>>>>>
> >>>>>>>> Hi Leo,
> >>>>>>>>
> >>>>>>>> I've done the tests based on you mail and my conclusion
> >>>>> is that the
> >>>>>>>> default value of LOCAL_USER should be ok for us. The
> >>>>>>> problem is that
> >>>>>>>> the variable USER is wrongly set, when you change users.
> >>>>>>>>
> >>>>>>>> I've done the tests, on :
> >>>>>>>>
> >>>>>>>> DVM 3.54.1a (under 3 different OS)
> >>>>>>>> WFE 3.54.2e (all under XP)
> >>>>>>>>
> >>>>>>>>
> >>> 
> --------------------------------------------------------------------
> >>> -
> >>>>>>> -
> >>>>>>>> ------
> >>>>>>>> ---------------------------------------
> >>>>>>>> O.S. LOCAL_USER=USER LOCAL_USER=@USR or @USERNAME 
> >>>>>>>> LOCAL_USER=@ENV{LOGNAME}
> >>>>>>>>
> >>>>>>> --------------------------------------------------------------
> >>>>>>> --------------
> >>>>>>>> ---------------------------------------
> >>>>>>>> Fedora Core 4 REMOTEUSER (*1) REMOTEUSER (*2)
> >>>>>>>> empty REMOTEUSER (*3)
> >>>>>>>> Red Hat 8.0 REMOTEUSER (*1) REMOTEUSER (*2)
> >>>>>>>> empty REMOTEUSER (*3)
> >>>>>>>> Solaris 8 unset REMOTEUSER unset REMOTEUSER
> >>>>>>>> unset REMOTEUSER
> >>>>>>>>
> >>>>>>> --------------------------------------------------------------
> >>>>>>> --------------
> >>>>>>>> ---------------------------------------
> >>>>>>>>
> >>>>>>>> (*1) REMOTEUSER obtains the value of the first USER set in
> >>>>>>> the ilogin
> >>>>>>>> "User" field. If you change it and then login, you keep
> >>>>> getting the
> >>>>>>>> original one. This is the BUG.
> >>>>>>>>
> >>>>>>>> (*2) REMOTEUSER gets the "windows network username" no
> >>>>> matter what
> >>>>>>>> username I use to login on the Linux/Unix server. This is
> >>>>>>> not what I
> >>>>>>>> need, maybe it's usefull for others.
> >>>>>>>>
> >>>>>>>> (*3) REMOTEUSER is set, but has an Empty value, even though
> >>>>>>> LOGNAME is
> >>>>>>>> set in the Linux/Unix environment.
> >>>>>>>>
> >>>>>>>> On Solaris the variable REMOTEUSER is always "unset" (not
> >>>>>>> empty, just
> >>>>>>>> unset).
> >>>>>>>>
> >>>>>>>> Then I tried to find out WHY we use that variable
> >>>>> REMOTEUSER, and
> >>>>>>>> tracked it down to cli-java. In cli-java, in the cjac.cnf
> >>>>>>> file, it is
> >>>>>>>> set with FGL_AUTHUSER (it came on the original example), so
> >>>>>>> we used it
> >>>>>>>> to obtain the REMOTE Username authenticated by the Web
> >>>>> Server. It
> >>>>>>>> never caused problems before, because we don't much use
> >>>>>>> "ilogin", and
> >>>>>>>> maybe most of the customers that do use it, have Unix
> >>>>>>> servers. So this
> >>>>>>>> problem hadn't happen before.
> >>>>>>>>
> >>>>>>>> So, I guess setting the REMOTEUSER variable is not a
> >>>>>>> FourJ's problem,
> >>>>>>>> so we can stop using it.
> >>>>>>>>
> >>>>>>>> But now we need to have another way to obtain the Remote
> >>>>> Web Server
> >>>>>>>> User, and we need a way that can work across all front-ends
> >>>>>>> (BDS and
> >>>>>>>> Genero) or to know excatly how to do it for each
> >>>>> front-end to build
> >>>>>>>> internal libraries to obtain that "user".
> >>>>>>>>
> >>>>>>>> Some more info on this matter :
> >>>>>>>>
> >>>>>>>> 1) in a mail with subject "[fourjs-users] Product News -
> >>>>> Four J's
> >>>>>>>> Business Development Suite 3.53 (FOUR J'SJAVA FRONT END)"
> >>>>>>> from April
> >>>>>>>> 2nd. 2003, it says :
> >>>>>>>>
> >>>>>>>>   ~ All JFE previous versions had specialized way to manage
> >>>>>>> browsers
> >>>>>>>> authentification
> >>>>>>>>     (via the variable FGL_AUTHUSER) and parameters 
> passed via 
> >>>>>>>> an URL.
> >>>>>>>>     In this version, all these features follow the same
> >>>>>>> standard than
> >>>>>>>> Web Front End.
> >>>>>>>>
> >>>>>>>> ~ For more information, please see the Discovering Web Front 
> >>>>>>>> End 3.53 documentation.
> >>>>>>>>
> >>>>>>>> I read that "Discovering WFE 3.53 documentation" and
> >>>>> couldn't find
> >>>>>>>> anything about it.
> >>>>>>>>
> >>>>>>>> 2) I searched all Genero documentation and couldn't find
> >>>>>>> how that same
> >>>>>>>> thing (Web Auth) is done in Genero. What I did found out
> >>>>>>> was that in
> >>>>>>>> our already "converted to Genero" programs, instead of using 
> >>>>>>>> REMOTEUSER, we are using a variable
> >>>>>>> "FGL_WEBSERVER_REMOTE_USER". I've
> >>>>>>>> searched all bds and genero user lists mails, and all my 
> >>>>>>>> FourJ's support mails, and couldn't find out where I 
> got that 
> >>>>>>>> info
> >>>>>>> from. But
> >>>>>>>> I've tested it with GDC-AX enabling HTTP Auth, and it works.
> >>>>>>>>
> >>>>>>>> So, if I want to use only one method for all the front
> >>>>>>> ends, is that
> >>>>>>>> FGL_WEBSERVER_REMOTE_USER the actual variable for all web
> >>>>>>> front-ends
> >>>>>>>> in BDS and Genero ? If so, can you point out the
> >>>>> documentation so I
> >>>>>>>> can analyze this further ?
> >>>>>>>>
> >>>>>>>> And if there isn't one unique way, can you tell me for each
> >>>>>>> of these
> >>>>>>>> front-ends, which is the way to obtain the 
> Authenticated User ?
> >>>>>>>>
> >>>>>>>> - BDS Cli-Html Client
> >>>>>>>> - BDS Cli-Java Client
> >>>>>>>> - Genero GDC-AX
> >>>>>>>> - Genero Java Client
> >>>>>>>> - Genero Web Client
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>>
> >>>>>>>> Florencia
> >>>>>>>>
> >>>>>>>>> -----Mensaje original-----
> >>>>>>>>> De: [email protected]
> >>>>>>> [mailto:[email protected]] En
> >>>>>>>>> nombre de Leo Schubert Enviado el: Miércoles, 22 de
> >>>>>>> Febrero de 2006
> >>>>>>>>> 12:44
> >>>>>>>>> Para: [email protected]
> >>>>>>>>> Asunto: Re: [fourjs-users] Unrespected Password Problem
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> MensajeHi Florencia,
> >>>>>>>>> it's true, by default WTK sets local user and remote user
> >>>>>>> to the same
> >>>>>>>>> value when logging in to a remote host via "rlogin" 
> protocol. 
> >>>>>>>>> However we added a resource in WTKSRV.INI to surround
> >>>>> this (since
> >>>>>>>>> version 3.54.1a) : [RLOGIN]
> >>>>>>>>>
> >>>>>>>>> ;;;;;;;;;;;;;;;;;;
> >>>>>>>>> ; Specify the local user sent in the rlogin protocol ; by 
> >>>>>>>>> default LOCAL_USER = USER ; you will need to set this 
> >>>>>>>>> explicitly here if the local
> >>>>>>> user ; is a
> >>>>>>>>> different one ; Default: value of USER ; LOCAL_USER
> >>> can be: ; ;1.
> >>>>>>>>> a real user name foo ;2. @USR -> the OS function
> >>> GetUserName() is
> >>>>>>>>> called ;3. @USERNAME -> the environment variable
> >>> USERNAME is used
> >>>>>>>>> ;4. @ENV{envname} -> an environment variable of 
> choice is used 
> >>>>>>>>> ;  ( @ENV{MYUSER} for example )
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> LOCAL_USER=@USR
> >>>>>>>>>
> >>>>>>>>> In your case I suggest to set LOCAL_USER TO "@USR" to let
> >>>>>>> WTK fill in
> >>>>>>>>> the actual Windows user name of the local user.
> >>>>>>>>> I didn't know that the REMOTEUSER environment variable
> >>> is now set
> >>>>>>>>> automagically from the rlogin daemon, but I can't find
> >>> any note
> >>>>>>>>> about that in the original RFC's 1258 and 1282  . Also
> >>> the rlogin
> >>>>>>>>> man page doesn't mention this. Is there any man 
> page where I 
> >>>>>>>>> can find this ? Kind Regards, Leo
> >>>>>>>>>
> >>>>>>>>> ----- Original Message -----
> >>>>>>>>> From: Florencia Vitale
> >>>>>>>>> To: [email protected]
> >>>>>>>>> Sent: Wednesday, February 22, 2006 3:14 PM
> >>>>>>>>> Subject: RE: [fourjs-users] Unrespected Password Problem
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Hi all,
> >>>>>>>>>
> >>>>>>>>> On this mail I'll give some more feedback on our actual
> >>>>>>> problem, so
> >>>>>>>>> to not lead to wrong conclusions.
> >>>>>>>>>
> >>>>>>>>> First of all, the case where the user typed in 3 
> times a wrong
> >>>>>>>>> password, we could not yet reproduce. I'll try to send a
> >>>>>>> consultant
> >>>>>>>>> to the customer asap, to clarify this. The customer
> >>>>>>> insist's on this
> >>>>>>>>> issue, and sends me printscreens, and all that, but I cannot
> >>>>>>>>> confirm for sure. And the consultant that wen't 
> last time, he 
> >>>>>>>>> didn't see that case really, but the other one. 
> Where the user 
> >>>>>>>>> changed the username after the second failure, and 
> succeeded 
> >>>>>>>>> login in with that second account, but saw the
> >>>>>>>>> first username on the terminal window, and on our 
> application
> >>>>>>>>> first screen.
> >>>>>>>>>
> >>>>>>>>> So here's my feedback on that second case (changin 
> usernames) 
> >>>>>>>>> :
> >>>>>>>>>
> >>>>>>>>> The problem wasn't a security issue at all, but a bug
> >>>>> (anoying but
> >>>>>>>>> not so critical) in the "ilogin" application. What
> >>>>> happens is that
> >>>>>>>>> "ilogin" sets the REMOTEUSER variable on the Linux
> >>> server, with
> >>>>>>>>> the original username, the one defined as default in the
> >>>>>>>>> shortcut, or the first one you set if there was no 
> >>> default user,
> >>>>>>>>> and not with the user that finally
> >>>>> logged in.
> >>>>>>>>> I found out, because I could finally reproduce it
> >>> here, against
> >>>>>>>>> Fedora Core 4, and there I saw that the Linux user was
> >>>>> Ok. (with a
> >>>>>>>>> "who" from another session). But the database conection
> >>>>> user, was
> >>>>>>>>> wrong. And that was because in our programs we use
> >>> REMOTEUSER if
> >>>>>>>>> it's set, as the Connection and Application user. 
> If it's not
> >>>>>>>>> set, we use the "SELECT user FROM table_with_one_row". 
> >>> We use the
> >>>>>>>>> REMOTEUSER because when we run a program from 
> cli-java or from 
> >>>>>>>>> GASD (in Genero) the Application Server always 
> connects to the 
> >>>>>>>>> database with the same user, which is the user that 
> runs the 
> >>>>>>>>> daemon. But we need the real username, which we obtain with
> >>>>>>>>> REMOTEUSER, when the user authenticates with
> >>>>>>>>> HTTP Auth, or any other Auth system we choose.
> >>>>>>>>>
> >>>>>>>>> So, the bug can be divided into 2 problems :
> >>>>>>>>>
> >>>>>>>>> - upon "ilogin" the internal variable @USER is wrongly
> >>>>>>> set. It always
> >>>>>>>>> shows as the original
> >>>>>>>>> (default) user. This is shown on the ilogin terminal
> >>> window and
> >>>>>>>>> confuses the user. This is not critical, and most of
> >>>>> the times we
> >>>>>>>>> don't even show the terminal window, in fact we only
> >>>>> activated it
> >>>>>>>>> for debugging issues.
> >>>>>>>>>
> >>>>>>>>> - the major problem is that probably that same @USER
> >>>>>>> variable is the
> >>>>>>>>> one that ilogin uses to set the server REMOTEUSER
> >>>>>>> variable. This is
> >>>>>>>>> only done with Linux servers, on Unix servers it
> >>> doesn't populate
> >>>>>>>>> that variable at all, as in fact it's not a remote 
> user, but a
> >>>>>>>>> user from the same server it's authenticating the 
> login. So I 
> >>>>>>>>> guess, it shouldn't be populated on Linux, as it's 
> not on Unix,
> >>>>>>>>> and also the @USER should be populated with the actual user
> >>>>>>>>> that logged in.
> >>>>>>>>>
> >>>>>>>>> I hope this give's some light upon my previous mail.
> >>>>>>>>>
> >>>>>>>>> Florencia
> >>>>>>>>>
> >>>>>>>>> -----Mensaje original-----
> >>>>>>>>> De: [email protected]
> >>>>>>> [mailto:[email protected]] En
> >>>>>>>>> nombre de Florencia Vitale Enviado el: Jueves, 16 de
> >>>>>>> Febrero de 2006
> >>>>>>>>> 11:39
> >>>>>>>>> Para: [email protected]
> >>>>>>>>> Asunto: RE: [fourjs-users] Unrespected Password Problem
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Hi Jennifer,
> >>>>>>>>>
> >>>>>>>>> Well, yes, it happened to a customer of us, too.
> >>>>>>>>>
> >>>>>>>>> If you search for a thread with subject "Ilogin 
> Authentication
> >>>>>>>>> problem" you'll see what I posted. But I got no real 
> >>> answer from
> >>>>>>>>> fourjs. After several tests here, in my environment, I
> >>>>>>> found that the
> >>>>>>>>> username was wrong on the window header, but the 
> real user had
> >>>>>>>>> logged in.
> >>>>>>>>>
> >>>>>>>>> Then the customer insisted that that was not their
> >>>>> case, and they
> >>>>>>>>> showed me that not changing the user, but putting the
> >>>>>>> wrong password
> >>>>>>>>> 3 times, lets the user log in, with that username, as
> >>> it's then
> >>>>>>>>> showed in the firt screen of out application where 
> we show the
> >>>>>>>>> username obtained from the database engine.
> >>>>>>>>>
> >>>>>>>>> But after Oliver's answer (see last mail of my thread)
> >>>>>>> I've tried to
> >>>>>>>>> solve this issue with our local support. No solution yet !!!
> >>>>>>>>>
> >>>>>>>>> Florencia
> >>>>>>>>> -----Mensaje original-----
> >>>>>>>>> De: [email protected]
> >>>>>>> [mailto:[email protected]] En
> >>>>>>>>> nombre de Jennifer Yu Enviado el: Miércoles, 15 de
> >>>>> Febrero de 2006
> >>>>>>>>> 18:22
> >>>>>>>>> Para: [email protected]
> >>>>>>>>> Asunto: [fourjs-users] Unrespected Password Problem
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Hi All,
> >>>>>>>>>
> >>>>>>>>> Has anybody come across the problem where a user may
> >>> type in any
> >>>>>>>>> password and still log onto the Windows Front End?  We
> >>>>>>> noticed this
> >>>>>>>>> issue in January 2006, but did not have this problem in the
> >>>>>>>>> previous years of using this product.  Our wtksrv 
> >>> files have not
> >>>>>>>>> been modified.  Telnet connection to the system still
> >>> checks if
> >>>>>>>>> the entered password matches what is saved for the user.
> >>>>>>>>>
> >>>>>>>>> Hopefully a solution exists since it is a security problem.
> >>>>>>>>>
> >>>>>>>>> Regards,
> >>>>>>>>> Jennifer
> >>>>>>>>>
> >>
> > 
>