Hi all,
I noticed an interesting problem that if you log in with something like
http://localhost/servlets/Turbine/screen/Login
then type in your user name and password, the next screen rewrites
the URL and redirects to the login page. The problem is that your
password shows up in the rewritten URL on the browser's location line!
One possibility for fixing this might be to use the servlet session
to include information about the 'next page' instead of through
rewriting the URL.
So the process would be that the user would log into the system in
whatever page they wanted. If login was required, that page would
save out all of its parameters into the session, then redirect to the
login. The login, when it was complete, would gather the information
from the session and bounce back to the originally requested page.
All of this would be done without any of the URL rewriting going
on...[and your password would not appear on the location line :)].
As a slight extension to this, we could add the ability to define
special screens (derived from Screen) called 'dialogs' which
encapsulated much of the 'preserve/restore my current page'
functionality. These 'dialogs' could be used for items such as logins
or for garnering other forms from users while keeping track of a more
basic flow through the system.
As a further extension, we could build some of the automatic
functionality of dialogs into the base 'Screen' class. In specific,
instead of just asking a screen for its content, we could add methods
for configuring the 'prerequisites' of any particular screen
automatically -- login would be one example... That way global items
such as login's could be controlled more easily and it would cease to
be a special case in the main servlet class... The prerequisites
could function on a global basis, per screen basis, or by some other
criteria.
Anyway, this message might be rambling on but I would love to work on
this stuff and if this sounds like a cool direction, I could provide
more detail and a cohesive description and eventually a bunch of code.
On a more specific front: has the project been trying to avoid
storing objects to the session object due to performance issues?
Chris Meyer
[by the way, if this was already covered in a previous discussion,
please excuse me. I'm making my way through the archives but I'm only
back as far a 3/1/00]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
