Re: 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
>>>>>>>>>
>>
>