RE: Web Server Authentication

Hi Sisavanh,

Now it's very clear.

Thanks a lot,

Florencia

> -----Mensaje original-----
> De: [email protected] 
> [mailto:[email protected]] En nombre de Sisavanh SENGSAVANH
> Enviado el: Jueves, 02 de Marzo de 2006 06:25
> Para: [email protected]
> Asunto: Re: [fourjs-users] Web Server Authentication
> 
> 
> Hi Florencia,
> 
>  
> > 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 ?
> 
> What is not recommended is the direct connection to GAS. This 
> is only for development and testing purpose. It is also for 
> security reasons, like firewall, https ... Which is usually 
> available with the Web Server but not yet with GAS. About 
> performance reasons, the load balancing is done by the cgi 
> (see connector.xcf). You can have several gasd running that 
> can serve the same application. The cgi will choose one among 
> the several gasd, to answer to the request. Which you cannot 
> do with a direct connection to gasd. You only have one possibility.
> 
> Does this clarify ?
> 
> 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 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
> >>>>>>>>>>>
> > 
>