>
> 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!
<form method="POST"> will prevent that. This isn't a Turbine issue, it is
the way that you wrote your <form> tag.
> 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.
It has nothing to do with that.
> 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 :)].
That is what data.getUser().setTemp() is for.
> 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.
Uh. Ok. This is generally thought of as more application specific and not
Turbine specific, but if this stuff can be re-used more generally, then
we should include it within Turbine so that everyone can benefit.
> 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.
Ok. Send a diff.
> 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.
That I like. ;-)
> On a more specific front: has the project been trying to avoid
> storing objects to the session object due to performance issues?
Absolutely not. There is a lot of stuff stored in the session right now.
By default, when someone hits the site, a User object is stored into the
session for that user. You can get at it with data.getUser(). Take a look
at the implementations...we are not storing much else directly within
the HttpSession because that doesn't give you much control. Instead, we
are storing things in the temporary storage and the permanent storage
within the TurbineUser object.
data.getUser().[g][s]etPerm()
and
data.getUser().[g][s]etTemp()
The temp storage is just a Hashtable that gets removed when the session
dies. The perm storage gets transparently serialized to the database in
the Visitor.ObjectData column if the user has been authenticated with the
system. The perm storage is a quite cool feature of Turbine because you
don't have to worry about saving user stuff to the database....it does it
for you. ;-)
> [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]
Nope, just read through the source code a bit more. ;-)
-jon
--
Scarab -
Java Servlet Based - Open Source
Bug/Issue Tracking System
<http://scarab.tigris.org/>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
