Re: Authentication

Peter wrote:

Would you look what I started!!

LOL yes, looks like many of us did have the same problem in mind :)

Thanks for all the pointers. How about using JavaScript to grab things like the OS + browser as *added* security?

Things are not so easy: we do have a set of classes doing exactly that, but the user may turn off Jscript at any moment and you would lose the chance to have your information confirmed. The very same thing happens if you store your stuff in cookies (which is why we do not use them at all), user may suddenly freak out and turn them off (I myself do that quite often, just for the fun of fooling cross-marketing companies). Nothing you can get from jscript should be used for security, simply because you have NO WARRANTY that jscript will be there (besides, what about us Lynx users?)

In the same way, the screen resolution, colour depth and other browser variables could be compared.

We do that, but to make it robust you must take into account the simple fact that you might end up in retrieving no data at all from the client. This is what I am working on these days. Basically, our class set is a shared core that applies to a number of customers (we plan to release it as PD in a short time). Local implementations just plug-in their extensions and use the robust core code underneath, which takes care of security implementation, user behaviour and settings tracking, engine portable database interaction and HTML formatting capabilities. The problem of missing jscript can be solved like this on any iframe enabled browser: start screen +---------------------+

!              +----+ !
!   A          !  B ! !
!              +----+ !

+---------------------+ A = main (that is index.html or whatever you want to use) B = control iframe A contains javascript routines that extract data and pass it to a script executed in B, which in turn loads all parameters in the session table, starts the session recording all user parameters and launches the real Home page in A. What if no Jscript? simple, B contains an autorefresh instruction that fires in 30 seconds, launching the loader with no parameters, so it gets executed anyway, and it informs the software that this session will not be able to execute jscript, which is really handy if you want to develop client-side jscript content checking routines to make a faster form interaction (this way you also know whether you can allow yourself using the onclick event for button objects instead of having submits within the current session). Now the loader checks parameter and if any of them is missing presents user with a form in A, where user can check them out himself. This is because nowadays the number of available screen resolutions is such that is hardly possible to imagine a design solution that would hold both on a java-enabled 1182x864 24 bit colour depth screen and on a no frills 640x480 8 bit colour thing. It has hardly anything to do with security because after all most of this user parameters may change during the visit (we are not building NATO or KGB intranets, right?) besides, you may want to check the same session with two different browsers at the same time yourself, to check some design behaviour both on Mozilla and IE. And what if no iframes? That part, my friend, is still quite obscure... but if I can make it work on Lynx I guess it will work for everybody... Suggestions are welcome, just remember that they must rely on an HTML only environment, since we cannot assume jscript or java to be there.

I do not see any reason for the user to log in and use my site, then later in the day come back to the homepage and expect to be automatically logged in which may simplify things a bit.

This is something you can trim anyway: if your user bookmarks the home page with the session parameter in the link he may do that at any time (provided you set an infinite expiration time for your content request and accept subsequest security relaxation, of course). And with no cookies at all, since, again, they might just NOT work. It's really risky on the web, but I can't see why people wouldn't use this within a secure intranet if they need to do so. In short, our structure is: Class Kuntach (it's the name of our company), which provides: 1) parameter authentication in a register_globals_off

      environment and intercepts data poisoning attempts.

2) database plugin (users have different DB techs, so

      code is portable among databases, provided they all accept
      standard ANSI SQL)

3) an remote error reporting routine (on dberrors or security

      alert all objects dump their content in readable format
      and mail it to you (plus they log the event to db)

4) an HTML manager plugin (we use the old fasttemplate, but it's

      a plugin, so...)

Class configuration_manager, which stoks all passwords, security level configuration, reporting configuration, plugin choice and so on. Class Request (extends Kuntach) which records a navigation step Class History (extends Kuntach) which is an ordered collection of all user steps within the current session Class SessionSlave (extends Kuntach) which: 1) contains an history object 2) retrieve parameters from a user session but has no way to

      alter it (which is used for the slave iframes, like menu
      objects, ad-objects, news objects, etc)

3) contains a customization plugin (see later) Class SessionMaster (extends SessionSlave) which adds the capability of extending the session (that is, objects of this class can issue navigation requests) Class SessionCreator (extends SessionMaster) which can obviously start a new session and assign it its code id Class Customization_plugin (extends Kuntach) which specifies 1) further parameters for local implementations. That is, not

      all sites will be happy with the set of parameters we maintain
      for a session, some of them will need more. This plugin adds
      them without touching core code, which must remain intact and
      portable "as is" among different servers, customers, etc.

2) site code, which is executed here, again by another plugin

      mechanism, so that you just write your scripts with NO OO
      STUFF (just has you inherited them from legacy). You may
      run OO code too, of course, classes just provide a wrapper
      for you to use your old scripts "as is". As a result, you
      just name the parameters that must be validated before
      running the old script and... BINGO! it runs, with
      your register_globals off and no modification to your
      stable legacy code. Which is really why we expect it to
      be a successful Open Source project.

That's the heart of it. If you want see the code it's no problem, because we will be releasing core classes as an open project in autumn anyway, so there's no secret about it. BTW, if anyone wants to play with us, you are welcome. The project will be called "Forest", but this may actually change, you know, marketing stuff... Code is definitely small-sized and so far it works perfectly even on our benchmark machine: linux 7.1, mysql 3.23.36 on pentium 166-mmx with 64m RAM. We are currently at version 0.2 for most classes, so this is really an early stage. Alberto Kiev -- @-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@ LoRd, CaN yOu HeAr Me, LiKe I'm HeArInG yOu? lOrD i'M sHiNiNg... YoU kNoW I AlMoSt LoSt My MiNd, BuT nOw I'm HoMe AnD fReE tHe TeSt, YeS iT iS ThE tEsT, yEs It Is tHe TeSt, YeS iT iS ThE tEsT, yEs It Is.......