add authentication via url for ics calendars

[Mark-Niemeyer]

Adds authentication via the URL of the calendar. In settings.json a URL with username and password can be used. Just add:

http://username:password@example.com/calendar

A mixed list of URL with and without authentication is possible.

All code changes are done in inkycal/modules/ical_parser.py. Therefore it works for inkycal/modules/inkycal_agenda.py and inkycal/modules/inkycal_calendar.py.

Fixes #163
The corresponding card

[aceisace]

Thank you very much for your PR @mhoellmann . I like the approach of a structured input which can be evaluated later. The direction this is heading to seems interesting too.
However, as the suggested changes in this PR aren't small, some time/adaptations might be required to integrate this in a way where this can be standardised.

[Mark-Niemeyer]

The approach of the structured input is taken from the authentication for basic auth via url (https://stackoverflow.com/questions/4980912/username-and-password-in-https-url). Nextcloud calendars are also accessible like this.

I tried to change as less as possible. Therefore just the load_url function was modified and it's backwards compatible. If any adaptions are required I'm happy to help.

[Mark-Niemeyer]

The approach of #187 could also be adapted for the username and password. Instead of http://username:password@example.com two query key words like inky_user and inky_password could be defined. But I still prefer the already implemented approach.

[maweki]

Just to add: http://username:password@example.com/calendar is specifically RFCs 2617 and 7617 and is not a custom invention. This is really the way this should be done and this is supported by basically all browser and tools. The only reason to do something else is a different mechanism for secret management that may be incompatible.

[worstface]

I don't think writing your google credentials into the settings.json file is that a great idea. Other than that I can imagine users pasting their google usernames and passwords to the internet whilst using this username+password+link combination auth method. If this was credentials for some restricted account that might be okay, but users pasting their google credentials into the settings.json file would be a security risk.

Even if this was established in IETF documents, these are over 20 years old and might be flawed seen from today's standards.

Could someone explain the benefit of this? Maybe I misunderstood how this works?

[maweki]

I don't think writing your google credentials into the settings.json file is that a great idea.

I am not aware of any google service that would support http basic auth. If you're currently using google calender, you have to have the "secret" url for your calendar. Exposing that is basically the same risk, or even riskier, as it's not clear which information is private and which is not. Accidentally exposing auth-tokens is much more likely for the layperson, than their password and username in plaintext.

Even if this was established in IETF documents, these are over 20 years old and might be flawed seen from today's standards.

This is still in use and works fine with any browser with the http or ftp protocols. My filemanager (nautilus/gnome) supports this for ssh/sftp/webdav. The user agent is supposed to extract the credentials and use them for the auth process.

Could someone explain the benefit of this? Maybe I misunderstood how this works?

It's established, well supported, a working solution, and doesn't need any newly invented method for authentication management. Again, if the issue is "secret information in the json-file", your auth-tokens (for openweathermap, for example) are at least as exposed. Secret management is a different mechanism.

[worstface]

I don't think writing your google credentials into the settings.json file is that a great idea.

I am not aware of any google service that would support http basic auth. If you're currently using google calender, you have to have the "secret" url for your calendar. Exposing that is basically the same risk, or even riskier, as it's not clear which information is private and which is not. Accidentally exposing auth-tokens is much more likely for the layperson, than their password and username in plaintext.

I have to disagree. Exposing the google credentials is of course more serious by some orders of magnitude than exposing one of your calendar links. By exposing the google credentials you are exposing all personal data, all emails, all passwords, credit card infos, browser history, all calendars, location data, personal cloud data and so on. So this has to be prevented under any circumstances. This should not be put in some inkycal settings file in plain text.

Even if this was established in IETF documents, these are over 20 years old and might be flawed seen from today's standards.

This is still in use and works fine with any browser with the http or ftp protocols. My filemanager (nautilus/gnome) supports this for ssh/sftp/webdav. The user agent is supposed to extract the credentials and use them for the auth process.

Of course 20 years ago it has been done like that. But sending credentials in plain text via (non encrypted) http is just not acceptable today.

Could someone explain the benefit of this? Maybe I misunderstood how this works?

It's established, well supported, a working solution, and doesn't need any newly invented method for authentication management. Again, if the issue is "secret information in the json-file", your auth-tokens (for openweathermap, for example) are at least as exposed. Secret management is a different mechanism.

Yes, the settings.json is not a safe space for secret things in my opinion. I think you really have to weigh the consequences.
Please compare what harmful things an evil agitator could do with your openweathermap auth token compared to what he could do with your google credentials (e.g. he could get your openweathermap auth token).

This still didn't answer my question what the benefit is. (Lets not consider my comments on security here)
What exactly would be my advantage using this auth method? (I just want to understand why there is an intention to do this)

[maweki]

Of course 20 years ago it has been done like that. But sending credentials in plain text via (non encrypted) http is just not acceptable today.

Credentials are not sent in plain text (edit: or more plain than any other authentication method). This URI schema is used so that the User Agent (our http(s) client) may extract the credentials and use them to perform the authentication. In the same manner, the URI fragment (everything after #) is not sent to the server but is purely used by the User Agent.

This still didn't answer my question what the benefit is.

It is the accepted way to inject credentials for an (arbitrary) authentication process. Currently, there is no way to do that in inkycal. An alternative would be to create a more difficult syntax, maybe an auth-object in json, that contains the credentials. But there is no need to reinvent the wheel, as there is already a tried and tested spec there on how to encode authentication details into URIs.

[Mark-Niemeyer]

Yes, the settings.json is not a safe space for secret things in my opinion. I think you really have to weigh the consequences.

Yes, it is a security issue to store the credentials in plain text on the raspberry, but is also a issue to leave my personal calendar without a password protection. I think when it comes to security questions everyone has to consider their own threat model.

I do not use the Google Calendar, so if you were able to get access to my calendar credentials, nothing else would be affected. So in my case there is on the one hand the very unlikely event, that someone gets access to my home network and the raspberry pi. On the other hand someone could retrieve my calendar without a password. Therefore, I prefer to store my credentials in plain text on the raspberry.

What exactly would be my advantage using this auth method? (I just want to understand why there is an intention to do this)

The advantage is that the user can decide by himself how he wants to fetch his calendar, because right now the user is forced to use a publicly accessible URL. That might scare some users off.
Of course the user should be aware of the security implications. And if I'd use my Google calendar I would really think twice whether I'd store my Google credentials in plain text.

[Mark-Niemeyer]

And as an example for the necessity of this: Those users who host their calendars in their own Nextcloud cannot create a public link for the birthday calendar of the contacts. Only a private link exists which requires authentication.

The feature for public link sharing is still missing, see here: nextcloud/calendar#1307

[github-actions]

Marking this PR as stale due to inactivity

[github-actions]

Marking this PR as stale due to inactivity