> -----Original Message-----
> From: Henning P. Schmiedehausen [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 20, 2003 11:34 AM
> To: [EMAIL PROTECTED]
> Subject: Re: cvs commit:
> jakarta-turbine-2/src/java/org/apache/turbine/services/pull
> TurbinePullService.java
>
>
> [EMAIL PROTECTED] writes:
>
> > User user = data.getUser();
> > + populateWithSessionTools(sessionTools, context,
> data, user, false);
> >
> > if (!TurbineSecurity.isAnonymousUser(user))
> > {
> > - populateWithSessionTools(sessionTools,
> context, data, user, false);
> > -
> > - if (user.hasLoggedIn())
> > - {
> > - populateWithSessionTools(authorizedTools,
> context, data, user, false);
> > - populateWithSessionTools(persistentTools,
> context, data, user, true);
> > - }
> > + populateWithSessionTools(authorizedTools,
> context, data, user, false);
> > + populateWithSessionTools(persistentTools,
> context, data, user, true);
> > }
> > }
>
> Nah.
>
> I'm firmly -1 on that change! Please revert it!
>
> I did think long and hard about this and I didn't introduce a
> fifth tool scope for no reason.
>
> If you have a session tool added with the anonymous user, you
> get these added to the anonymous users temp data. This
> happens in the Velocity Service _before_ the login action is
> run. Now you log an user in and get a new user object
> _without_ the session tools and your first screen will not
> have any session tools.
But this is a breaking change. It has been possible up until now to
have session pull tools available before the user logs in. There is a
Scarab issue for the the issue with losing the session scope tools after
the login executes. I have a simple hack in my application to avoid
this problem.
I am looking at a way to fix the problem with session scope tools being
removed by login. IMHO, session scope tools should not be in the user.
They should be in the session. I just don't have this working cleanly
enough to commit yet.
> And the authorized scope is absolutely vital for my
> application as I have a tool which _must not_ be accessible
> from an non-authorized user. Please keep the check for the
> hasLoggedIn() around this.
TurbineSecurity.isAnonymousUser() will return true only is the user has
logged in. If the login action fails for any reason, the anonmous user
is left in the session. It seemed to me that isAnonymousUser() and
hasLoggedIn() perform exactly the same function as you will never have a
non-anonymous user that is not logged in.
> This is the main distinction between session and authorized.
> I'm willing do discuss if we can find a way to better define
> the semantics for a session tool, but as long as these are
> saved in the user objects' temp table, it is pretty moot to
> add them to the anonymous user because it is thrown away at
> login time.
I think that your authorized tools are still only added for users that
are logged in. Can you see a case where isAnonymousUSer() will return
true for a user that is not logged in?
> If you run the full request cycle after a login, then it
> would work. But you don't. You just do a setScreenTemplate.
Again, Storing session pull tools in the session should provide a way to
avoid this problem. Also, the authorized tools could be stored here as
well since Turbine.logoutAction() now invalidates the session as part of
the logout process.
> Regards
> Henning
>
>
>
>
>
>
>
>
> >
> > @@ -433,7 +429,7 @@
> > }
> > catch (Exception e)
> > {
> > - log.error("Could not instantiate global tool "
> > + log.error("Could not instantiate global tool "
> > + toolData.toolName + " from a "
> > + toolData.toolClassName + " object", e);
> > }
> > @@ -456,7 +452,7 @@
> > {
> > // Fetch Object through the Pool.
> > Object tool =
> pool.getInstance(toolData.toolClass);
> > -
> > +
> > // request tools are init'd with a RunData object
> > initTool(tool, data);
> >
> > @@ -465,7 +461,7 @@
> > }
> > catch (Exception e)
> > {
> > - log.error("Could not instantiate request tool "
> > + log.error("Could not instantiate request tool "
> > + toolData.toolName + " from a "
> > + toolData.toolClassName + " object", e);
> > }
> > @@ -485,7 +481,7 @@
> > * permanent storage (as opposed to the temporary storage).
> > */
> > private void populateWithSessionTools(List tools,
> Context context,
> > - RunData data, User user,
> > + RunData data, User user,
> > boolean usePerm)
> > {
> > // Iterate the tools
> > @@ -525,22 +521,22 @@
> > }
> > }
> >
> > - // *NOT* else
> > + // *NOT* else
> > if(tool != null)
> > {
> > // This is a semantics change. In the old
> > // Turbine, Session tools were
> initialized and
> > // then refreshed every time they
> were pulled
> > // into the context if
> "refreshToolsPerRequest"
> > - // was wanted.
> > - //
> > - // RunDataApplicationTools now
> have a parameter
> > + // was wanted.
> > + //
> > + // RunDataApplicationTools now
> have a parameter
> > // for refresh. If it is not
> refreshed immediately
> > // after init(), the parameter
> value will be undefined
> > // until the 2nd run. So we
> refresh all the session
> > // tools on every run, even if we
> just init'ed it.
> > //
> > -
> > +
> > if (refreshToolsPerRequest)
> > {
> > refreshTool(tool, data);
> > @@ -558,7 +554,7 @@
> > }
> > catch (Exception e)
> > {
> > - log.error("Could not instantiate session tool "
> > + log.error("Could not instantiate session tool "
> > + toolData.toolName + " from a "
> > + toolData.toolClassName + " object", e);
> > }
> > @@ -646,7 +642,7 @@
> > }
> > }
> > }
> > -
> > +
> > /**
> > * Initialized a given Tool with the passed init Object
> > *
> >
> >
> >
>
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> [EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/
>
> Java, perl, Solaris, Linux, xSP Consulting, Web Services
> freelance consultant -- Jakarta Turbine Development -- hero for hire
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
