Hiding a Portlet in a Filesystem Package

[Derek Richardson]

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