Skip to content

Don't invalidate access token after each request #50

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
igneus opened this issue Sep 2, 2020 · 7 comments · Fixed by #55
Closed

Don't invalidate access token after each request #50

igneus opened this issue Sep 2, 2020 · 7 comments · Fixed by #55

Comments

@igneus
Copy link

igneus commented Sep 2, 2020

Is your feature request related to a problem? Please describe.

When I authenticate using access token and user ID (rather than username and password), first request passes, but the second and any further request always results in error 401 Unauthorized and my precious access token disappears (from the access token administration in RocketChat UI).

import os

chat = RocketChatAPI({
    # authenticate using a personal access token
    'user_id': os.getenv('ROCKETCHAT_USERID'),
    'token': os.getenv('ROCKETCHAT_TOKEN'),

    'domain': 'https://my.domain.eu',
})

# make first request to find a room
all_rooms = chat.get_public_rooms()
room_name = 'name'
room_id = [x for x in all_rooms if x['name'] == room_name][0]

# attempt second request, which fails with 401 Unauthorized
chat.send_message('Message text', room_id)

It turned out that it's because after each request a call to RocketChatBase.logoff() is made, which calls the deadly /api/v1/logout endpoint, which does exactly what the documentation says:

Invalidate your REST API authentication token.

Describe the solution you'd like

When authenticating using access token, the library should never call RocketChatBase.logoff() on it's own.

Describe alternatives you've considered

I don't see any reasonable alternatives.

Additional context

No additional context available.

@pipozzz
Copy link
Member

pipozzz commented Sep 4, 2020

Seems legit, I'll check that purpose and let you know.

@makew0rld
Copy link

@pipozzz Something related I've noticed is that it seems that when I provide a username and password, a login call is made to get an auth token... for every single API call. it would be much more efficient if the login call is made only once, when RocketChatAPI is initialized, and the token was cached from then on. Let me know if I've misunderstood something.

@makew0rld
Copy link

Also it would be good if being able to use a user ID and token was documented in the docs.

@igneus
Copy link
Author

igneus commented Sep 9, 2020

when I provide a username and password, a login call is made to get an auth token... for every single API call.

Yes. A login call before and a logoff call after.

@JargeZ
Copy link

JargeZ commented Sep 16, 2020

I think I understand the reason for this behavior. For example, so that after scripts that are run once many times, there are not many tokens left on the server with access to the account.

I also think that you can not call the logoff after each request, but add the one-time-login bool parameter to the settings, which will say that after each request the user session will be killed by calling /api/v1/logout
By default we can make it true
The current behavior will be preserved.
For authorization by login/password, there will not be many sessions in small scripts.
But it will be possible to use this setting to work with api in larger scripts and manually call the logoff if necessary ❤️

@JargeZ
Copy link

JargeZ commented Sep 16, 2020

Also, for login/password authorization you can use one-time-login=False to increase performance and not make two extra requests to the api.
To implement this, we can add the token+user_id encrypted with the specified password to the .authdata file (as example)

What do you think about this?

@pipozzz
Copy link
Member

pipozzz commented Sep 18, 2020

I didn't find any serious reason for calling logoff after each call, so I think we can avoid using it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants