Skip to content
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

[12.0][MIG] auth_api_key from 10 to 12 #56

Merged
merged 20 commits into from
Feb 14, 2019

Conversation

sbidoul
Copy link
Member

@sbidoul sbidoul commented Nov 20, 2018

Migration of #51

TODO

@sbidoul sbidoul added this to the 12.0 milestone Nov 20, 2018
@OCA-git-bot OCA-git-bot mentioned this pull request Nov 20, 2018
19 tasks
@lmignon
Copy link
Contributor

lmignon commented Nov 20, 2018

@sbidoul the last commits of #51 are missing and should fix travis

  • [FIX] add oca dependencies 1aa57d8
  • [FIX] Travis: add [running_env] section into openerp_serverrc: b55f684

@lmignon
Copy link
Contributor

lmignon commented Nov 20, 2018

@sbidoul The name of the migrated module is auth_api_key not server_auth 😏

@sbidoul sbidoul changed the title [12.0][MIG] server_auth from 10 to 12 [12.0][MIG] auth_api_key from 10 to 12 Nov 21, 2018
@sbidoul
Copy link
Member Author

sbidoul commented Nov 21, 2018

🍏

Copy link
Contributor

@RobinetDenisAcsone RobinetDenisAcsone left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seem good to me, just a small request

continue

login_name = serv_config.get(section, "user")
uid = self.env["res.users"].search(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sbidoul Is it possible to modify to search also the active=False users?

Note: The suggestion below is 83 char (too long), but suggestion on multi lines isn't possible

Suggested change
uid = self.env["res.users"].search(
uid = self.env["res.users"].with_context(active_test=False).search(

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure. I kind of remember people (was it @guewen?) saying running code under an inactive user was a bad idea, but I'm don't remember why.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sbidoul I do not know on further versions but at least on V10.0 I have absolutely no troubles while running code with an inactive technical user....

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lmignon any opinion on this?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sbidoul IMO we must keep the possibility to select an inactive user (it's under the responsibility of the integrator/administrator to select the most appropriate one active or inactive). We must keep in mind that (at least in odoo < 12) active users are paid users. That's why we use inactive users in such use cases.

Copy link
Member

@guewen guewen Dec 12, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure. I kind of remember people (was it @guewen?) saying running code under an inactive user was a bad idea, but I'm don't remember why.

The problem with inactive users is that they will be removed from the group that they are in as soon as you edit the user list on an ir.group. The m2m widget for users on the group will not include them - as they are inactive, so if you changes the list, it will remove it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not know on further versions but at least on V10.0 I have absolutely no troubles while running code with an inactive technical user....

Neither on other versions, until you edit the other users on a group and wonder why suddenly it doesn't work anymore ;)

@gurneyalex
Copy link
Member

@sbidoul #51 is merged, was there anything you needed to pick from that PR before this one gets merged?

@ap-wtioit
Copy link
Contributor

ap-wtioit commented Dec 12, 2018

@gurneyalex this addon depends on server_environment which is not yet migrated to 12.0 (or 11.0) in https://github.com/OCA/server-tools

i could add the code suggestion from our private repo where we removed the dependency if that is ok

@sbidoul
Copy link
Member Author

sbidoul commented Jan 25, 2019

@ap-wtioit server_environment is merged in https://github.com/OCA/server-env

Co-Authored-By: qgroulard <43472442+qgroulard@users.noreply.github.com>
@sbidoul
Copy link
Member Author

sbidoul commented Jan 25, 2019

@gurneyalex I've cherry-picked the consteq commit of @ap-wtioit, so this is now ready to merge.

@lmignon
Copy link
Contributor

lmignon commented Feb 13, 2019

Is everyone agreed to merge?

@ychirino
Copy link

Blunt question: How many sessions are created by this implementation for 1.000.000 requests during a time span of 7 days? - I wonder if it's 1.000.000 or if I'm missing something...

@sbidoul
Copy link
Member Author

sbidoul commented Feb 13, 2019

@ychirino In my experience, there is no sessions issue, as long as the client handles cookies properly. For python clients, using request.Session() is easy enough.

It might be worth mentioning in the readme of auth_api_key, though.

@ychirino
Copy link

@sbidoul Yeah, I wondered. Thanks. My main concern is a bearer token approach for an external API client. I can't guarantee in no way that it would stick to this pretty please recommendation. For more details see this comment.

@ychirino
Copy link

ychirino commented Feb 13, 2019

Maybe a k/v map in memory assigning each token to a session? It's not a canonical solution but would reduce that problem by some orders of magnitude.
Assuming that workers power cycle every hour (7d * 24h * 5w * 10apikeys) 8.400 sessions vs 1.000.000 c.p.

@sbidoul
Copy link
Member Author

sbidoul commented Feb 13, 2019

@ychirino multi-db is not really supported by this module at the moment.

Regarding the session, I'm not sure what problem you want to solve. It's easy to ask clients to return cookies.

@ychirino
Copy link

ychirino commented Feb 13, 2019

@sbidoul There is a POC implementation of a bearer token here.

The problem depends on what "easy" in "easy to ask clients to return cookies" actually means. On a publicized API It assumes cooperative clients. I'm not sure that's a valid assumption.

Or did I miss something here?

@sbidoul
Copy link
Member Author

sbidoul commented Feb 14, 2019

@ychirino api keys and bearer tokens are for different use cases. api keys are meant for cooperating clients indeed. If you need bearer tokens that's for another module.

BTW, this is a migration PR, so please do not pollute it with unrelated comments.

.. |badge1| image:: https://img.shields.io/badge/maturity-Beta-yellow.png
:target: https://odoo-community.org/page/development-status
:alt: Beta
.. |badge2| image:: https://img.shields.io/badge/licence-AGPL--3-blue.png
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose that the licence badge will be fixed once the PR will be merged and the readme re generated

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes

@lmignon lmignon merged commit 80605d5 into OCA:12.0 Feb 14, 2019
@lmignon lmignon deleted the 12.0-mig-auth_api_key branch February 14, 2019 10:29
@ychirino
Copy link

ychirino commented Feb 14, 2019

@lmignon Thanks for the clarification indeed, is a more extensive topic.

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

Successfully merging this pull request may close these issues.