[ADD] Download user iCal with res.users.apikeys in URL.

[amh-mw]

Description of the issue/feature this PR addresses:

There is no way for a user to synchronize their calendar directly from Odoo.

Current behavior before PR:

Two-way CalDAV synchronization was retired in OpenERP 7?

Desired behavior after PR is merged:

One-way read-only iCalendar synchronization from Odoo using a specially crafted URL containing a res.users.apikeys value. Calendar key setup has been added to account security tab in user preferences.

---

I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

[tivisse]

@amh-mw Thanks for the feedback.

Well, I wouldn't approve this PR at the first sight for the following reason:

• I'm not fond of adding a new authentication mechanism (see: https://github.com/odoo/odoo/pull/53986/files#diff-e6bce60073e5b2c72561523cfefbc79dR34). It seems fishy to introduce a new mechanism without any justifications. The commit message lack a real purpose, a complete specification, and an argumentation about why this is impossible to use the standard auth mechanism. Starting from that, I wouldn't merge it even if it was correct.

• If I get it correctly, you refer the basic authentication method in http (See: https://en.wikipedia.org/wiki/Basic_access_authentication). It means that the request from the outside contains your Odoo password in the headers, which seems alors very fishy. I didn't take time to imagine some use cases, but there is a risk of introducing a security flaw over here.

I'm still open to the discussion ;)

Cc @odony maybe you have another point of view to bring here.

Have a nice day,

Yannick.

[amh-mw]

@tivisse I am currently migrating to Odoo from another CRM and one of the parity features currently lacking is the ability of sales/service employees to synchronize their work calendar directly to their phones. I'd be happy to use (and implement) any authentication mechanism that is broadly supported across iOS and Android calendar applications (research into this topic TBD). We are HTTPS-only, so the HTTP Basic headers are encrypted at that layer at least, but given that Odoo supports running in non-HTTPS mode, I agree with your concern. Comparing this to the XML-RPC External API, it seems that password is sent on every call?

https://www.odoo.com/documentation/13.0/webservices/odoo.html#list-records:
models.execute_kw(db, uid, password, ...)

[amh-mw]

I read up on RFC 3744, RFC 7616, Passlib and Werkzeug for a bit today. The modern pbkdf2_sha512 hashing of our passwords does not appear to be an algorithm supported by HTTP Digest, so that seems like a dead end for authentication.

I notice that Odoo uses access tokens for various behaviors (calendar invites, document signing), perhaps a per-user access token could be appropriate here for read-only calendar access? It could still be SHA-512 hashed with a nonce on the wire via HTTP Digest.

[tivisse]

Hi @amh-mw

Thanks for your answer.

You're right. Indeed https encrypts the headers. And indeed Odoo allows http. This could be a leak, as for xml-rpc, or even simple login. But we don't want to add a new authentication mechanism if it's not the only solution that works.

I was looking at the way Google Calendar works to share easily a calendar, and I found that you may generate a private iCal address with a token from which you can retrieve all your events.

Something like
https://calendar.google.com/calendar/ical/bruce.wayne%40gmail.com/private-my-super-token/basic.ics

This would imply to store my-super-token on the res.users table for example, while handling correctly the privacy of this information (groups on the field), and maybe a button to reset the token.

See:

What do you think ?

cc @mart-e

Have a nice day,

Yannick.

[amh-mw]

@tivisse That generally seems reasonable. Let me work it up.

[amh-mw]

I'm not in love with the latest prototype, especially that the token is dumped into the logs on every call. I also prototyped this with an URL signature of /calendar/basic.ics?login=LOGIN&token=TOKEN and that is also dumped into the logs.

What about HTTP Basic or Digest against the access token instead of the password?

[amh-mw]

I read up on RFC 2617 for a bit and implemented HTTP Digest for qop=auth, algorithm=SHA-512. I feel pretty good about this one, testing in iOS Calendar now.

[tivisse]

Hi @xmo-odoo

After a small discussion with @odony it appear that this whole new feature is overlapping (at least partly) your work on API keys.

We should check with @antonylesuisse to decide if reject this or try to integrate it into your work.

What do you think ?

Thanks !

[xmo-odoo]

After a small discussion with @odony it appear that this whole new feature is overlapping (at least partly) your work on API keys.

The access_token seems to be overlapping with the "api keys" idea, especially with the addition of scopes to keys by @Florimond

Though the biggest blocker so far is obviously that the entire thing is still in limbo waiting for @odony's seal of approval.

[amh-mw]

Any chance I could get a link to the api keys work? I didn't find anything relevant searching for is:open is:pr author:xmo-odoo archived:false. I would absolutely make use of scoped keys; as a workalike right now I have created "api users" with specific permissions to simulate this. I'm coding full time right now on nothing but Odoo, so let me know if there is any work along these lines that I could contribute to.

[amh-mw]

Returning to the original thread, my testing with Apple Calendar in the iOS Simulator results:

• HTTP Basic
• HTTP Digest algorithm=MD5
• HTTP Digest algorithm=MD5-sess
• HTTP Digest algorithm=SHA-256
  Initial 401, then calendar takes no subsequent action.
• HTTP Digest algorithm=SHA-512
  Typo on my part, SHA-512 isn't on the IANA Hash Algorithms for HTTP Digest Authentication list.
• HTTP Digest algorithm=SHA-512-256
  Initial 401, then calendar takes no subsequent action.

[xmo-odoo]

Any chance I could get a link to the api keys work? I didn't find anything relevant searching for is:open is:pr author:xmo-odoo archived:false. I would absolutely make use of scoped keys; as a workalike right now I have created "api users" with specific permissions to simulate this. I'm coding full time right now on nothing but Odoo, so let me know if there is any work along these lines that I could contribute to.

@amh-mw it's part of the 2FA/TOTP work as (obviously) once totp is enabled we can't allow using passwords for RPC as that would defeat the purpose, so API keys of sort are introduced as part of that. I couldn't tell you where @Florimond is working on his extension and scope system.

[Julien00859]

Review for addons/calendar_ical/models/ir_http.py only, LGTM. I don't know for the feature itself though