Install auth_oauth and via the /web/login, click the "Log in using
Odoo.com" button. You are redirected on odoo.com which ask you for your
odoo.com login and password. When the login form on odoo.com is
submited, you are redirected back on your local database.
The problem is that, in case a new account was created on-the-fly, then
the login fails with a cryptic error. The actual error is that
`request.env.user._is_internal` fails because `user` is an empty
recordset where it should had been the just-authenticated user.
The problem is an inconsistent transaction state between the cursor of
the request, the cursor used with `auth_oauth` (which created a new
user) and the cursor used with `authenticate` (which authenticated the
new user). Yes, there are 3 cursors. The newly created user just isn't
present in the transaction of the request's cursor.
Here is the lifetime of the 3 cursors:
* request.env.cr, it begins when the http request enters Odoo, it is
commited when a http response exits Odoo.
* /auth_oauth/signin, it begins roughly at the beginning of the
controller, it is commited once after the user is created (so before
the authenticate transaction begins but AFTER the request transaction
begun), it is commited again when the controller exits.
* authenticate, begins when authenticate is called, is commited when it
returns.
Because the request transaction started before, it cannot access user
created by /auth_oauth/signin.
Because the route is `auth='none'`, if system administrators append the
`auth_oauth` module via `--load` (cli) or `server_wide_modules` (odoorc)
then the controller can be accessed without database. This is the reason
for the explicit registry/cursor/environment inside this controller, we
needed to make sure we are connected to a database, we cannot rely on
request.
The new approach used in this work is to benefit from `ensure_db()`, the
function that is used by various web `auth='none'` controllers such as
/web and /web/login. It makes sure that the database we want to connect
to is already present on the request, otherwise it repeats the request
but this time connecting it to the database. Using this approach we can
have a `auth='none'` controller whose request.env is guaranteed to be
connected on the right database. We can avoid to create explicit new
registry/cursor/environment within the controller and just use request's
ones.
Because the /auth_oauth/signin controller now simply use the request
transaction, the above point:
> Because the request transaction started before, it cannot access user
> created by /auth_oauth/signin.
just doesn't stand anymore as the user is created within the same
transaction. The extra `cr.commit()` must still be present for
`authenticate` to see the newly created user.
opw-3421701
closesodoo/odoo#138051
X-original-commit: e165568f9795af213c8467a7f17948ed781b0799
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
Co-authored-by: Julien Castiaux <juc@odoo.com>
Use the `fragment_to_query_string` decorator before the `route`
decorator on a controller endpoint. Traceback when the endpoint is
called as a `str` object is not a `Response` object.
Since httpocalypse it is advised that all decorators used with http-type
controllers return a Response. This makes it possible to decorate the
endpoint in any order, even before `@route`.
# Preferred
@route(...)
@fragment_to_query_string
def endpoint(...):
...
# This work
@fragment_to_query_string
@route(...)
def endpoint(...):
...
X-original-commit: 4a879cb4a395ad5ef47384937fcc383acdb3e431
Part-of: odoo/odoo#110034
No method was readily available to know if a user is `internal` (has
group `base.group_user`), which was inconsistent with other base groups.
_is_internal is now used in the codebase where it is clear that
`.has_group('base.group_user')` is called on a single record.
Part-of: odoo/odoo#85703
I apparently missed this case in #88871: Google's legacy
flow (response_type=token) explicitly rejects a `nonce` parameter
being passed in the authentication request. The nonce parameter is
only accepted for an OIDC-conformant implicit flow request (aka
`response_type=token id_token`).
The specific endpoint doesn't seem to have any bearing on this, v1 and
v2 authentication endpoints result in the same behavior.
Drawback: Okta isn't supported anymore, as it requires the nonce, no
if, no but, even on "legacy" auth requests, possibly others. However
since these already weren't supported that's considered less of an
issue than possibly breaking compatibility with existing IDP.
Rejected alternative: adding `id_token` to the `response_type` to come
closer to OIDC-conformant request, however that was considered too
risky: Odoo clients could be using legacy IDP which also reject the
nonce parameter but don't have a magic "OIDC conformant" trigger.
closesodoo/odoo#91500
X-original-commit: 1fd738d9826f9bdfe8deddd5ef81dcb9757e8988
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Olivier Dony <odo@odoo.com>
The current implementation is rather non-standard and largely an
ad-hoc pre-RFC implementation, with a number of incompatibilities with
the standard & actual real-world identity providers (IDP).
Tested with the following IDP:
- google oauth v1
- google oauth v3
- auth0
- okta
Add support to bearer Authorization
===================================
Sending the access token via "Authorization: Bearer $TOK" is strongly
recommended by the RFC, and required for all IDP to support. The query
parameter method is a legacy compatibility method and should be
avoided.
Query parameter access tokens are supported by Google (both v1 and
v3), and auth0, but not okta. All three support bearer tokens. However
making this the default is complicated by compatibility issues with
current behavior.
Use standard `sub`ject for identity
===================================
The specification defines `sub` as the userinfo key providing the user
identifier at the IDP.
- auth0, okta, and google v3 use `sub`
- google v1 uses `id`
- google v1's `tokeninfo` (possibly v3 as well, not tested) uses
`user_id`
- odoo replicates the google v1 tokeninfo behavior, using `user_id`
All the code is now standardised on `sub`, with `_auth_oauth_validate`
performing unification under that key.
Support non-json error bodies and WWW-Authenticate
==================================================
Per-spec, there is no requirement for error (userinfo) responses to
return any body, and all error information can be returned via
`WWW-Authenticate`.
Both auth0 and okta return empty bodies on error, though only okta
returns a useful www-authenticate, or relevant 40x statuses (auth0
seems to always return 400, okta has been observed to return both 400
and 401 depending on client error).
Error handling in `_auth_oauth_rpc` has been updated to only parse the
body as json on success (200), and fallback on a generic error payload
if `WWW-Authenticate` doesn't contain relevant information.
Nonce
=====
Okta requires a nonce to be provided.
Misc
====
A few improvements which are in no way required but should make things
simpler / clearer:
- update the default scope to match the standard for the implicit
flow's values (intersected with our requirements)
- update the default google configuration to use the v3 endpoints and
drop the tokeninfo request, remove the explicit scopes
- update the label of `validation_endpoint` to match the official
terminology, same with `auth_endpoint`
- add a label to `body` in order to explain what it's for (as that's
really confusing when the form just says `body` until you hover the
field)
Expected future updates
=======================
These issues were left out and may lead to degraded security, but were
considered too large changes fora stable compatibility-oriented
update:
* store and validate the nonce
* request and properly validate the id token, as well as validate the
access token (implicit guide sections 2.2.1, 2.2.2)
* implement "basic" flow[^basic], and / or "hybrid" flow, the implicit
flow[^implicit] is intended for purely client-side applications
(SPAs), the "authorization code" flow is intended as the primary
flow for normal web applications involving a server component,
the main advantage of the hybrid flow is that the id token *can*
contain the claims selected by `scope`, avoiding the need for the
userinfo request[^idtoken]
* remove support for query parameter requests
* remove support for Google's v1 oauth and subject identifiers other
than `sub`, facebook has not been tested but looks to support that
key as well in the OpenGraph API[^fb], this will require migrating
existing google providers to v3 implicitly (but would allow
simplifying their configuration)
References: RFC 6749, RFC 6750, Implicit Client Implementer's Guide
1.0 draft 23[^implicit]
Closes#88618, closes#64348, fixes#63963, closes#63970,
closes#69568
[^implicit]: https://openid.net/specs/openid-connect-implicit-1_0.html
[^basic]: https://openid.net/specs/openid-connect-basic-1_0.html also
known as "authorization code" flow
[^fb]: https://www.facebook.com/.well-known/openid-configuration
[^idtoken]: during testing, only auth0 returned the additional claims
as part of the id token, but this may be a configuration
issue
closesodoo/odoo#91262
X-original-commit: fb3c4845b1549bc2e1378620a5f01e52aa4dbbdb
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The odoo.addons.web.controllers.main python module have been splitted
over multiple files on the basis 1 controller = 1 file. In this work we
adapt all modules to use the new imports.
A non-exhaustive list of where stuff have been moved:
* main.Home --> home.Home
* main.Session --> session.Session
* main.WebClient --> webclient.WebClient
* main.clean_action --> action.clean_action
* main.ensure_db --> home.ensure_db
The complete list is accessible in odoo.addons.web.controllers.main.
closesodoo/odoo#87571
Related: odoo/enterprise#25746
Signed-off-by: Raphael Collet <rco@odoo.com>
This commit is the 12th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
The web module is twofold, on one side there are many controllers: /,
/web, /web/login, /web/database/selector, /web/dataset/call_kw, etc, on
the other side there is `session_info`: the method responsible to create
the web client's environ.
This module is kinda an exception as it is (with base) a server wide
module. In the case of the HTTP framework, it means that the controllers
of web are always accessible, i.e. going to / or /web/login will never
return a 404 Not Found even if the user is not connected to a database.
This is both a blessing and a curse. It is a blessing because the
controllers are always accessible it means that a new users can freely
access those routes. It is a curse because *any* user can access them,
even user who don't have a session yet thus who are not connected to a
database yet. From a developer standpoint, we have to put extra care to
correct serve users with and without a database. An example is the
/web/login route, the login/password pair is stored in a database,
without database it is impossible to validate a user login but users can
still access this route without db.
To solve this problem, there is the `ensure_db` function. This function
attempts to find a database using various sources (?db= query-string,
session db, mono db) and to save it on the user session. In case no db
is found, the user is redirected to the database selector. In a way,
this function grants a database to the user in a seamingly experience.
In a way, this function brings a welcome differentiation between
`auth='none'` with a database and `auth='none'` without a database. Such
differentiation only matters for the server wide modules as "regular"
module controllers are only accessible via the ir.http routing map, i.e.
it is not possible to declare a nodb controller outside of server wide
modules.
An important changement is the `session.authenticate` method, before it
was possible to call the method when the cursor was not yet initialized,
authenticate would open a cursor against the given database, setup a
registry and an environment and ultimately save everything on the
current request. Because the cursor is now greedily created, it is no
more possible to update the request environment when authenticating on
another database.
PR: odoo#78857
Task: 2571224
This branch adds request.redirect on all requests.
In case of a front end request, we do an url_for to the location.
We removed redirect_with_hash that was only for retro compatibility
local_redirect has been renamed to redirect_query, and param keep_hash has been
removed and moved.
Default code for redirect is 303 now instead of 302.
Now redirect and redirect_query make local redirect by default, you need to
pass local=False to make external redirect.
All werkeug.utils.redirect has been replaced by request.redirect.
Http.redirect now use an http.Response type, and it become easy to add an
override like 'set_cookies' e.g.
Dispatch of a website.page return an http.response too, so we first need to
check if it is a cached version before to check if it is an Odoo Response.
Migrate your code:
http.redirect -> request.redirect(location, code, local)
http.local_redirect -> request.redirect_query(location, query, code, local)
http.redirect_with_hash -> request.redirect
Courtesy of odony for help and review ;)
closesodoo/odoo#72599
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
In 0.15 accessing werkzeug.urls functions directly through werkzeug
is deprecated, the shortcut will be removed in the eventual werkzeug
1.0.
Fix existing uses of these shortcuts. Also cleanup some imports when
they're not far from a werkzeug* import being altered.
Before this patch, if some module was based on top of `auth_signup`, and `auth_oauth` was also installed in the same database, the only way to get the proper qcontext would be to call `super()` inside `web_auth_signup_qcontext`, which would produce a login, which is most likely not desired because such addon would try to add some logic on top of it that maybe prevents login based on some circumstances.
After this patch, any submodules can work properly without workarounds.
closesodoo/odoo#34690
Signed-off-by: Christophe Simonis <chs@odoo.com>
Before this commit, a portal user would land on /web after login in with oauth.
He would then just see the "Website" app.
He should then click on it to land on website instead of landing directly on it
after login in, which is not convenient, especially since theses users doesn't
know Odoo (in case of sale customers manually created for instance).
Now, if users has no 'base.group_user' right, it will be redirected to the
website directly instead of /web.
Even if there is only one provider,
you could still use the internal login rather than
this oauth provider to sign in,
and therefore you need to remain on the regular
login page if you would like to reset your internal password
The stdlib version of the json library is more recent than the 3.5.3
version we are pinning in `requirements.txt`
There is no reason to use it.
Closes#6940
Rebranding has been done in:
- data/demo files
- html templates
- help notices
- comments
- logger messages
- and other various messages
(Commit taken from odoo-dev:8.0-improve-openerp-odoo-rlu at rev 7deaa08)
Closes#1260
Most probably due to github migration
+ fix: directly redirect to login redirect paramas, instead of redirecting on the complete web/login + redirect url
