flask-login current_user is always flask_login.mixins.AnonymousUserMixin on connect, even though the user is authenticated

[Mimameid]

As the title mentions, I can't acces the current_user. The user authenticates via http beforehand, meaning current_user is available on any http endpoint.

This is the setup:

...
app = Flask(__name__)
socketio = SocketIO(app, cors_allowed_origins="*", async_mode='gevent')
...

And using it:

@socketio.on('connect')
def connect():
    global thread_lock
    global bg_thread
    with thread_lock:
        if bg_thread is None:
            if current_user.is_authenticated:
                bg_thread = socketio.start_background_task(db_listen_task)

What am I missing?

[miguelgrinberg]

It's hard for me to tell. You need to debug this to determine where is the problem. Is the browser sending your Flask session cookie in the Socket.IO connection request? That would determine if the connect event can see your user or not.

[Mimameid]

Thanks for the fast reply. It was one of my assumptions. Chrome Debugger tells me this:

So I assume, the cookies are sent along.

[miguelgrinberg]

As I said above, I cannot debug your application from here. You should do that.

To the best of my understanding, sessions are preserved. You can use the sessions.py example in this repository (maybe remove the Flask-Session extension) to test how sessions work. If you find a case in which sessions do not work as intended then create a small and complete example application for me to review.

[Mimameid]

All good. It was hard to tell, if the session cookie as included. See below post.

[Mimameid]

Wait, I think I need to correct myself. Which one of these is the initial request, that triggers the connect event?

[Mimameid]

@miguelgrinberg I think I found the culprit. It seems like I have to set on the client the following option: {withCredentials: true} which defaults to false. Thank you for your time.

[miguelgrinberg]

This is only necessary if you are doing a cross-origin request. Should not be needed in the normal case of hosting the regular and Socket.IO applications together.

[Mimameid]

You are right. Updated our client site app to sent request in development via a proxy to the same origin. Now the { withCredentials: true } option is no longer needed.