Skip to content

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

Merged
lmignon merged 20 commits into
OCA:12.0from
acsone:12.0-mig-auth_api_key
Feb 14, 2019
Merged

lmignon merged 20 commits into
OCA:12.0from
acsone:12.0-mig-auth_api_key

Conversation

@sbidoul

@sbidoul sbidoul commented Nov 20, 2018

Copy link
Copy Markdown
Member

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

lmignon commented Nov 20, 2018

Copy link
Copy Markdown
Contributor

@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

lmignon commented Nov 20, 2018

Copy link
Copy Markdown
Contributor

@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
sbidoul force-pushed the 12.0-mig-auth_api_key branch from 6da46a7 to 8edf0bc Compare November 21, 2018 10:00
@sbidoul

sbidoul commented Nov 21, 2018

Copy link
Copy Markdown
Member Author

🍏

@RobinetDenisAcsone RobinetDenisAcsone left a comment

Copy link
Copy Markdown
Contributor

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
Copy Markdown
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
Copy Markdown
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.

Copy link
Copy Markdown

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
Copy Markdown
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
Copy Markdown
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.

@guewen guewen Dec 12, 2018

Copy link
Copy Markdown
Member

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
Copy Markdown
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
Copy Markdown
Member

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

@ap-wtioit

ap-wtioit commented Dec 12, 2018

Copy link
Copy Markdown
Contributor

@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

sbidoul commented Jan 25, 2019

Copy link
Copy Markdown
Member Author

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

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

sbidoul commented Jan 25, 2019

Copy link
Copy Markdown
Member Author

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

@lmignon

lmignon commented Feb 13, 2019

Copy link
Copy Markdown
Contributor

Is everyone agreed to merge?

@ychirino

Copy link
Copy Markdown

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

sbidoul commented Feb 13, 2019

Copy link
Copy Markdown
Member Author

@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
Copy Markdown

@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

ychirino commented Feb 13, 2019

Copy link
Copy Markdown

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

sbidoul commented Feb 13, 2019

Copy link
Copy Markdown
Member Author

@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

ychirino commented Feb 13, 2019

Copy link
Copy Markdown

@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

sbidoul commented Feb 14, 2019

Copy link
Copy Markdown
Member Author

@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.

Comment thread auth_api_key/README.rst
.. |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
Copy Markdown
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
Copy Markdown
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

ychirino commented Feb 14, 2019

Copy link
Copy Markdown

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

SiesslPhillip pushed a commit to grueneerde/OCA-server-auth that referenced this pull request Nov 20, 2024
Syncing from upstream OCA/server-auth (10.0)
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.