[dev] [commits] Horde branch master updated. 18a53c7ffc56dd4df59a389b1f366a7089f51df6

Michael M Slusarz slusarz at horde.org
Wed Jul 22 19:22:34 UTC 2009


Quoting Jan Schneider <jan at horde.org>:

> Zitat von Michael M Slusarz <slusarz at horde.org>:
>
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>>
>>>>  This is the only place guaranteed to run logintasks on both regular and
>>>>  transparent auth. However, it may not be appropriate to run logintasks
>>>>  if we are doing some kind of API call.  It might be better to simply run
>>>>  all login tasks for all applications on initial login.
>>>
>>> Agreed, though only if authenticating through the login page.
>>
>> As opposed to what other methods?  I'm not sure I agree with this  
>> statement, since, for example, horde login tasks must *always* be  
>> run before the first time a page is displayed (e.g. for terms of  
>> service agreement).
>
> I'm talking about non-ui authentication, like SyncML, API calls,  
> etc. I didn't mean transparent authentication, sorry for the  
> confusion.

For this (and for other reasons) it does make sense to refactor  
pushApp() a bit to allow configuration of whether logintasks should be  
run or not.  The pushApp() call in app's base.php file should always  
have this set (even if they don't have logintasks, horde logintasks  
need to be run).  And I changed things so if permission/auth checking  
is disabled, logintasks shouldn't be run (this should take care of  
helper scripts, etc.).

API calls are a bit more difficult.  Example: I have an IMP login task  
to delete sent-mail folders past a certain age.  If I make an API call  
to list folders in IMP, this login task *must* be run before returning  
the list.

michael

-- 
___________________________________
Michael Slusarz [slusarz at horde.org]



More information about the dev mailing list