You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Randy Watler <rw...@finali.com> on 2004/11/22 06:51:20 UTC

Re: J2 Customizer Issues

David,

I have done some significant cleanup in the PageManager and the Customizer
updates seem to be working for me at this point. I think it is safe to say
that the CastorXmlPageManager version out there now is causing at least some
of the problems you are encountering. Will have a patch in the morning at
some point.

As I replied earlier, the security settings on "/" are preventing you from
viewing the root folder back link after decending into the Public folder. It
is possible to define the access permissions on a folder to be the union of
all of its children's access permissions, but that seems like it might be
too computationally intense to be worth it. I don't know what is best. For
now, you can propagate the current constraints in "/" folder.metadata to its
children and open the permissions on the "/" folder itself to allow guest
access.

I am currently having issues with the SiteBrowserPortlet: it apparently does
not set the JAAS subject before it accesses the PageManager. Since the
access is now checked in the PageManager and Folder access methods, it is
getting SecurityExceptions. I have just started looking into this, but am
taking a break until morning.

Talk to you then,

Randy

Re: J2 Customizer Issues

Posted by Randy Watler <rw...@finali.com>.
Ate:

I see the security stuff is working for you, :).

See inline comments below:

Randy

Ate Douma wrote:

>
>Is a message missing from the list or did you get a message from 'David'
>privately?
>
Yes, David sent a message to Scott and I wonding about issues he was 
having with the Customizer.

>
>I'd like to add another problem I encountered. Because the guest user now is
>a proper user, we should think of some way to disallow login to this user
>as it is meant to be used as buildin/internal user only.
>
>A simple solution to that would be setting the user is_enabled flag to
>false, but that still leaves the possibility someone enables it again
>through the UserManager.
>
>I personally would like to see a stronger protection against login of this
>user. This could be done by adding one more boolean attribute to the
>security_credential table (like is_buildin) or a hardcoded check in the
>UserManager.authenticate against the anonymous username. This name
>(default 'guest') is now managed by the Profiler though, so maybe we
>should move it to the UserManager then.
>
+1, seems like a good idea to limit the login.

>
>Another issue: the security rules on the Administrative folder won't allow
>a non-admin user to change its password. I will move the
>change-password.psml into the root folder to fix this.
>  
>
I checked in this change to restrict access to the Administrative 
folder, but I did not spend a whole bunch of time to reorganize the demo 
site to make sense. David has mentioned over and over again that he was 
going to go for it one of these days, so I left it to him. Of course, 
change password needs to be available to every user! Sorry if this 
caused you too much grief...

>If time permits, I will also check in tonight the second part of my
>JS2-151 issue containing enforced password change on first login. This
>includes automatic navigation to the Change Password psml with no way to
>navigate from it until the password is changed (logoff is still a way out
>though).
>Also included is a configurable set of days before password expiration
>when a user will be asked to change its password. The last day before
>expiration will require the password to be changed.
>
>These features are currently *not* (longer) working though as result of the
>new 'guest' user configuration which now *also* is required to change its
>password, even if this user isn't logged on at all.
>Kinda blocking problem :(
>I need this handled before I will check in my changes.
>
Thanks for the notice. I will hold off on upgrading my production site 
until we get this worked out.

>Regards,
>
>Ate
>
>  
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Re: J2 Customizer Issues

Posted by Ate Douma <at...@douma.nu>.
Randy Watler said:
> David,

Is a message missing from the list or did you get a message from 'David'
privately?

>
> I have done some significant cleanup in the PageManager and the Customizer
> updates seem to be working for me at this point. I think it is safe to say
> that the CastorXmlPageManager version out there now is causing at least
> some
> of the problems you are encountering. Will have a patch in the morning at
> some point.

I'd like to add another problem I encountered. Because the guest user now is
a proper user, we should think of some way to disallow login to this user
as it is meant to be used as buildin/internal user only.

A simple solution to that would be setting the user is_enabled flag to
false, but that still leaves the possibility someone enables it again
through the UserManager.

I personally would like to see a stronger protection against login of this
user. This could be done by adding one more boolean attribute to the
security_credential table (like is_buildin) or a hardcoded check in the
UserManager.authenticate against the anonymous username. This name
(default 'guest') is now managed by the Profiler though, so maybe we
should move it to the UserManager then.

Another issue: the security rules on the Administrative folder won't allow
a non-admin user to change its password. I will move the
change-password.psml into the root folder to fix this.

If time permits, I will also check in tonight the second part of my
JS2-151 issue containing enforced password change on first login. This
includes automatic navigation to the Change Password psml with no way to
navigate from it until the password is changed (logoff is still a way out
though).
Also included is a configurable set of days before password expiration
when a user will be asked to change its password. The last day before
expiration will require the password to be changed.

These features are currently *not* (longer) working though as result of the
new 'guest' user configuration which now *also* is required to change its
password, even if this user isn't logged on at all.
Kinda blocking problem :(
I need this handled before I will check in my changes.

Regards,

Ate

>
> As I replied earlier, the security settings on "/" are preventing you from
> viewing the root folder back link after decending into the Public folder.
> It
> is possible to define the access permissions on a folder to be the union
> of
> all of its children's access permissions, but that seems like it might be
> too computationally intense to be worth it. I don't know what is best. For
> now, you can propagate the current constraints in "/" folder.metadata to
> its
> children and open the permissions on the "/" folder itself to allow guest
> access.
>
> I am currently having issues with the SiteBrowserPortlet: it apparently
> does
> not set the JAAS subject before it accesses the PageManager. Since the
> access is now checked in the PageManager and Folder access methods, it is
> getting SecurityExceptions. I have just started looking into this, but am
> taking a break until morning.
>
> Talk to you then,
>
> Randy
>


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org