AnsweredAssumed Answered

RSS & Changing the authentication mechanism for Template

Question asked by sacco on Feb 5, 2008
Latest reply on Feb 22, 2008 by schneika
Is it possible to change or force the authentication mechanism (mechanism in the
sense used by acegi) used by Alfresco for, say, some or all scripts and/or
templates?  That is, I know it can be done in acegi, but I don't know how
Alfresco makes this setting and, more importantly, what might be the other
consequences of changing it.

Background:  I've been experimenting with Templates/Scripts to produce
RSS feeds for spaces. The examples given on the Wiki are all strictly for 
Guest  access, but we need to run as an authenticated user (and in any case
don't necessarily want to give Guest access to all the spaces where a feed
could be useful): 

Although the RSS spec says nothing about authentication, many clients
can already do this, particularly those which are browser add-ons.  The
good news is that with a bit of fiddling it already seems possible to
use Alfresco + Templates/Scripts with some of these, but only in the case
    login credentials must be presented up front (e.g. a Web-service call)
    a session can be established through a login page.
For example, one might be looking at the feed in a browser that has
already received a session ticket in a cookie, or else the browser might
display the login page, effectively as an 'error' message.

Other clients, however, lack the ability to accept and present  the
credentials 'up front', but will prompt the user for a username and
password if asked to perform DIGEST or BASIC authentication by the

The only thing, therefore,  that is lacking for a reasonably effective
implementation of private feeds, is the ability to make the server
challenge the client for DIGEST or BASIC authentication for certain
non-interactive URLs.

There should be an easy way to configure this: can anybody tell me where ?

Alternatively, it would be useful to have a converse setting to the 
?guest=true  parameter:  where
    ?guest=true  means
    'run the script as guest'

    no setting  means 
    'run as the current user if already logged in;
    otherwise try to get credentials through the login page, and run as guest only if this fails;

    ?guest=false  means 
    'challenge the client to authenticate with DIGEST (or BASIC)'
Or perhaps that's too much over-loading, and another parameter is
required (or more values for the setting).

Another way to achieve this behind an Apache front-end would be to hook
an external authentication mechanism onto the end of the chain, and then
to offer DIGEST/BASIC only for specific URLs, but this would be far more
complicated and depends on several other issues.