Re: Web Server Authentication

Hi Forencia,


> 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
> ?
> 
> And related to this last question, is there a way to set Authentication on a
> Genero Web Client, using "direct port connection" ?
> 
> 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
>>>>>>>>
>