[FLOW3-general] Session (autostart=false)

[Peter Russ]

--- Original Nachricht ---
Absender:   "Christian Müller (Kitsunet)"
Datum:       23.10.2011 11:20:
> Hi Peter,
>
>>> On 22.10.11 22:41, Peter Russ wrote:
>>>> Interesting Aspect: FLOW3 uses annotations to add aspects for
>>>> domain driven design. But due to that I have to rewrite?
>
> I don't get this in respect to your problem?
>
>>
>> Here the question:
>> <---->
>> Can anyone please show me how to disable session auto-start e.g.
>> \TYPO3\FLOW3\Security\Authentication\AuthenticationProvider->authenticate
>>
>> As we have stateless server/server communication we don't need sessions.
>> <--->
>>
>> Is there a way to disable auto-starting sessions using yaml e.g in
>> Objects.yaml or is this a missing feature?
>>
>> As mentioned: for 08/15 applications it might be helpful to auto-start
>> session. But using FLOW3 for enterprise level middle-ware applications
>> it doesn't make sense not being able to adjust that.
>>
>> Could I provide enough information?
>>
>
> So let me rephrase this: You want to build some server to server
> communication with authentication, but this should not create a session
> but only authenticate for a single request?
>
> I think I answered that already. Look for scope session annotation and
> override the respective objects with your own implementation to avoid
> scope session. Or add an aspect that drops the session at the end of the
> request, should work too.
>
> Maybe Karsten has more ideas. :)
Hi Christian,

we don't plan, we have a server to server communication authenticating 
each request.
Worked like a charme (Beta 1/Beta2) until we updated to final version of 
FLOW3 ;-)
Reason: 
\TYPO3\FLOW3\Security\Authentication\AuthenticationProviderManager->authenticate 
has got the new annotation @FLOW3\Session (autostart=true)

So the questions are:
1) Can I set this to autostart=false using Objects.yaml
2) Could this be handled by Objects.yaml but the feature is not 
implemented yet.
3) Is the only option we have to write our own provider class?

You see our problem: small changes in FLOW3 annotations brakes our 
application. Our preferred solution would be 1) or 2), but never 3)!



-- 
Fiat lux! Docendo discimus.
_____________________________
uon GbR

http://www.uon.li
http://www.xing.com/profile/Peter_Russ