Martin Aspeli wrote:
Derek Richardson wrote:
Hey. I'm writing a package to provide a Plone 3.0-compatible UI for
PAS4CAS - a replacement for PloneCASLogin, which has not been updated.
The basics work. I now want to hide the login portlet, since it is
non-functional and confusing with CAS.
Really? Why? If CAS (what is it?) means you're always logged in, then
the portlet shouldn't show up anyway (it only shows up for anonymous);
if CAS requires some kind of explicit log in/log out, then you could
customise/override/supplement the login portlet with that action.
Ah. CAS is a strange beast. It's actually a separate website that people go to
to authenticate. After they auth, it redirects them back to the originating
website with a ticket that the originating website can verify their identity
with. But at no point does the originating website see their password.
So, the original PloneCASLogin replaced the Login portlet with a new portlet
that just had a button to log in. But this takes up a bunch of screen real
estate for something that is done equally well by the 'login' link on the
personal bar. So, I figure, it'll be an improvement to just remove the portlet
altogether.
I *could* make it so that the login portlet talked to CAS and did the auth for
the user, so they wouldn't have to go to the CAS site. However, while I don't
know about other sites, at Georgia Tech, people like to see the CAS site when
they log in. It is comforting for the security conscious, since they know that
the CAS server will only talk to apps on campus and they know they can type
their kerberos creds into it without worry. This keeps kerberos creds from being
exposed to all the apps on campus, which is a *good* thing.
So, to answer your question, CAS does not mean you're necessarily always logged
in (since our Plone site may be the first site in the SSO set that you hit) (and
since we have content available to anon users who may never log in) and it's not
desirable to have Plone in between the user and CAS.
I'm in a filesystem package, so my first thought was to remove the
portlet using GenericSetup. Alas, no luck - the handler in
plone.app.portlets seems to only support adding portlets, not removing
them. I'm contemplating extending this handler to remove portlets, as
well. I'd then put the extended handler in my product and submit a
patch for plone.app.portlet.
Being able to remove portlets in the GS handler would be nice (and the
GS handler needs more work, as we've talked about before). However, this
is a bit extreme - it won't be possible to add a new login portlet
anymore once the portlet has been uninstalled like this;
Right, that's what I want. Though, if they uninstall my package, then I'd want
to restore the ability to add login portlets. /me makes mental note.
> also, I'm not
sure if this would actually remove existing instances of the login portlet.
Aha, I will have to figure out how to do this.
I'd say that this is not really something that belongs in a package that
contains a PAS plug-in, by the way. The PAS plug-in ought to be generic
enough not to have dependencies on Plone specifics such as the portlets
implementation. Perhaps a higher level package that had the PAS4CAS
package as a dependecy could contain this instead?
Oh, right. I wasn't clear. PAS4CAS by regebro provides the actual PAS plugin
with no deps on Plone. My package is merely a Plone 3.0 UI adjustment to use
PAS4CAS. So, I think I'm doing exactly what you suggest.
Questions:
1 - Is there a better way to hide the login portlet from a filesystem
package than to do it through GenericSetup?
You could just remove the assignment from the root of the site?
So, remove the portlet from being displayed but not remove its definition. Yes,
this would work. I still favor the more comprehensive solution, so that admins
don't think they can just add a login portlet and bypass the CAS redirect. But
perhaps I have too little trust. ;)
2 - If I patch the portlet handler, is this likely to be accepted
back? If so, what is the first plone version in which it is likely to
be allowed in? I must admit, I'm a little confused by 3.0.x vs 3.1 vs
3.5/4.0 and what is allowed in each. ;)
If you extend, rather than change the handler, it'd be a good candidate
for 3.1.
I was thinking this syntax for the XML:
<portlet removename="Login" />
That simple. This directive would remove all the instances of the portlet
definition with the given name (specified as 'title' in the addview directive)
and remove the ability to add them to the site. If both 'addview' and
'removename' were both present on the same <portlet />, then addview would take
priority and the removename wouldn't fire. What do you think?
You would need to do this work on a branch, by the way. :)
It looks like it would only affect portlets.py, be a few lines of code, and
would preserve back-compat with the current portlets.xml. Since I *still* have
not sent in my paperwork <duck />, can I just submit a patch?
Derek
_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers
