Sessionless token sets session cookie?

Hello fellows!

One question about sessionless auth tokens:

I have implemented a controller with only one action one can call with a user token.
Therefore I’ve defined a “appSingleToken”, regarding suggestions in
sessionless tokens here.

Thus my implementation looks like this:

class appSingleToken extends AbstractToken implements SessionlessTokenInterface {
 ....
}

This works, but I’m wondering about this produces a cookie named “TYPO3_Flow_Session”.
I’ve expected: no session = no session cookie.

What is wrong? My assumption or my implementation or both?
As I said: it works but I want to understand the mechanism…

Thank you!

Hi Frank,

the Flow session should not be started, so no TYPO3_Flow_Session cookie should be set.
You can check the system log to see what actually started the session. If it is the authentication there might be something wrong with your configuration.
But it can also be that some other @Flow\Session(autoStart=true) initiated it…

Hello Bastian!

Thanks for your reply.
I’ve checked the logs. There are no unusually entires.
In “security.log” only one line

Successfully authenticated token: token:"xxxx..."

as expected. Strange!

Hi @mexoona

Could it be that you have that cookie from a different request, and the actual cookie has nothing to do with the sessionless authentication your are working on now? Try and empty all cookies, try with a different browser or anything that will ensure that your browser session is clean.

Hello!

Sorry no. Newly started browser and only one request with a token.
the action is a service like REST. One request, one response with a dataset…

@mexoona can you share what

./flow configuration:show --type Settings --path Neos.Flow.security.authentication

outputs for you?

It is a Flow 3.3 installation. therefor:

./flow configuration:show --type Settings --path Flow.security.authentication
Configuration "Settings: Flow.security.authentication" was empty!

Try

./flow configuration:show --type Settings --path TYPO3.Flow.security.authentication

in that case

Here it is:

providers:
    FsxICalProvider:
        provider: FSX\customerApp\Security\Authentication\Provider\FsxICalProvider
        providerOptions:
            authenticateRoles:
                - 'FSX.customerApp:ICal'
    DefaultProvider:
        provider: PersistedUsernamePasswordProvider
        entryPoint: WebRedirect
        entryPointOptions:
            routeValues:
                '@package': FSX.customerApp
                '@controller': Login
                '@action': index
authenticationStrategy: oneToken

@mexoona So most probably the DefaultProvider starts the session. Can you disable it and try if that works?
If you don’t need it, you can ofc remove that configuration.
Otherwise make sure to use Request Patterns to explicitly control which provider ought to be active for which request.

Hello Bastian,
now back to this project (lots of work an others).

I’ve commented out the default provider. But still the same behavior. First I thought "disabling"
did not work, but output of “configuration:show” was as expected:

providers:
    FsxICalProvider:
        provider: FSX\customerApp\Security\Authentication\Provider\FsxICalProvider
        providerOptions:
            authenticateRoles:
                - 'FSX.customerApp:ICal'
authenticationStrategy: oneToken

Surprisingly the call to our login form sets no cookie until one tries to login (which fails of course).
Some other suggestions?
As I noted above: the systems works. I’m only interrested what’s going wrong here.