Bug 27305 - Use low privileged tokens to enable authenticated iCal feed
Summary: Use low privileged tokens to enable authenticated iCal feed
Status: In Discussion
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low enhancement (vote)
Assignee: David Cook
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-12-23 17:45 UTC by Nico Bako
Modified: 2022-05-11 05:57 UTC (History)
4 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 27305: Use low privilege tokens to enable authenticated iCal feed (23.74 KB, patch)
2021-04-19 07:04 UTC, David Cook
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Nico Bako 2020-12-23 17:45:26 UTC
As a user, when I browse the books that I am currently borrowing from the library, I can download the due dates as an ical file. This is wonderful, but it would be really nice to be able to have an RSS feed (a url link) to this calendar. That way I can sync the due dates to my personal calendar, like Gmail, for example. I can add an RSS feed to my personal calendar, and it will automagically populate my personal calendar with the due dates.

Thank you in advance!
Comment 1 David Cook 2020-12-23 22:48:50 UTC
I think that you probably mean an iCal feed rather than a RSS feed. 

It's an interesting idea. I can certainly see the appeal. 

I haven't implemented something like that myself, but it would have security implications. Google calendar seems to only be able to use URLs with embedded secrets, so it's not very secure. 

I would say your best bet is to bring it up with your particular library, and then maybe they'll look at getting someone to create the enhancement.
Comment 2 Nico Bako 2020-12-24 00:45:43 UTC
Thanks for the quick response.

Yeah, I definitely mean iCal feed.

I had some success trying to come up with a hacky solution. The link to my iCal (via my library account) is:

https://catalog.hmcpl.org/cgi-bin/koha/opac-ics.pl

I thought that if I set up my iCal feed to be:

https://catalog.hmcpl.org/cgi-bin/koha/opac-ics.pl?userid={user-id}&password={password}

then it should work... but this only worked as long as I was logged in. Once I logged out that link no longer worked.

The CRAZY thing is, this curl command works:

curl https://catalog.hmcpl.org/cgi-bin/koha/opac-ics.pl -d 'userid={user-id}&password={password}'

No joke, the curl command works!

Do you have any other ideas for a hacky way to get the iCal feed to work? I know that my solution has security implications (since my userid and password are part of the url)... but it might be a good workaround for now.

I did talk to my library, and they said they weren't aware of an iCal feed feature, but that they would look into it.
Comment 3 David Cook 2020-12-24 01:04:10 UTC
(In reply to Nico Bako from comment #2)
> I had some success trying to come up with a hacky solution. The link to my
> iCal (via my library account) is:
> 
> https://catalog.hmcpl.org/cgi-bin/koha/opac-ics.pl
> 
> I thought that if I set up my iCal feed to be:
> 
> https://catalog.hmcpl.org/cgi-bin/koha/opac-ics.pl?userid={user-
> id}&password={password}
> 
> then it should work... but this only worked as long as I was logged in. Once
> I logged out that link no longer worked.
> 
> The CRAZY thing is, this curl command works:
> 
> curl https://catalog.hmcpl.org/cgi-bin/koha/opac-ics.pl -d
> 'userid={user-id}&password={password}'
> 
> No joke, the curl command works!
 
Koha's authentication and authorization code is a pet peeve of mine :p. 

With the browser, you have already have an anonymous session (indicated by a browser cookie) after logging out, so it's prompting you to sign in again. 

With cURL, you're not sending a browser cookie, so it accepts your credentials to create a new session.

> Do you have any other ideas for a hacky way to get the iCal feed to work? I
> know that my solution has security implications (since my userid and
> password are part of the url)... but it might be a good workaround for now.
> 

I wouldn't call it a good workaround ;). As you say, including your credentials in a URL is a very bad idea.

That said, your hack might work with Google calendar for instance. I wouldn't be surprised if it did.

But... I do have plans to prevent userid and password from being sent via query string parameters. Your hack actually gives me more incentive to do that, in fact ;). 

> I did talk to my library, and they said they weren't aware of an iCal feed
> feature, but that they would look into it.

Which library is it?
Comment 4 Nico Bako 2020-12-24 02:30:04 UTC
Haha, yeah, sending user name and password as parameters is not a good idea...

So far I've tried that url (with user name and password) with Google calendar and it doesn't seem to work. I'm going to try a few more things, and if I figure out something that works I'll definitely let you know. If anything, it might give you even more inspiration for improving the security ;)


My library is Huntsville Madison County Public Library.
Comment 5 Nico Bako 2021-01-02 17:39:34 UTC
Update: the url I have mentioned above (with user name and password provided) works for my Google calendar feed.

Since this is all I really wanted to do, and I am quite happy with the solution, feel free to close this issue if you want to.

Yeah, I know it's not secure to pass user name and password in a url, but I only use this url on my Google calendar, and if my Google account gets hacked, then I have other more serious stuff to worry about...

What I would really like to see, to help make the authentication more secure, is to have another way other than providing user name and password in the url. Many sites provide the ability to create an API token which can be used for authentication instead. Something like that would be great, but probably outside the scope of this issue.
Comment 6 David Cook 2021-01-03 23:20:02 UTC
(In reply to Nico Bako from comment #4)
> My library is Huntsville Madison County Public Library.

It looks like Bywater Solutions is probably the vendor for that one. Hopefully Huntsville get in touch with them, as it would be an interesting feature.

> What I would really like to see, to help make the authentication more
> secure, is to have another way other than providing user name and password
> in the url. Many sites provide the ability to create an API token which can
> be used for authentication instead. Something like that would be great, but
> probably outside the scope of this issue.

I'm not 100% sure what you mean by "API token" in this case. Koha already uses short-lived API tokens using OAuth2 for its HTTP API. I'm guessing you might mean something like an "API key" although even then you'd want to send it via a HTTP header or as POST data for security purposes.

However, for your use case, you really do need some kind of generic authentication token that can be put into a URL parameter. It would be interesting to create "read tokens" with minimal fine-grained authorization. For instance, a read token that can only access your current due dates. That way someone can't re-use that token to review your past reading history, access your personal information, etc. 

> Yeah, I know it's not secure to pass user name and password in a url, but I
> only use this url on my Google calendar, and if my Google account gets
> hacked, then I have other more serious stuff to worry about...

I understand that perspective, but the thing is your Google account doesn't have to be hacked. I don't intimately know Google's internal security practices, but storing a password in plain text that presumably any Google employee could read is not great. Or storing a password in plain text in the event that say all Google calendar links get leaked/dumped without any accounts being breached per se. 

But since this is a case of one person exploiting a quirk in the system... it's probably not a huge drama. And it is one that I hope will be closed in the future ;).
Comment 7 Nico Bako 2021-01-04 19:59:02 UTC
Thanks a lot for the advice, David.

> I'm not 100% sure what you mean by "API token" in this case.

I'm thinking about how GitHub has "personal access tokens" 

https://docs.github.com/en/free-pro-team@latest/github/authenticating-to-github/creating-a-personal-access-token

But that might be too complicated to implement, and probably unnecessary for a library system.

> Koha already uses short-lived API tokens using OAuth2 for its HTTP API.

I actually just checked this out, and I think you are referring to the REST-API instead of the SVC-API. I have tried using the REST-API, but I continue to get `{"error",:"Authentication failure."}`. Either I'm doing something wrong, or I just don't have access to some of the API endpoints. According to this page: https://wiki.koha-community.org/wiki/REST_api_RFCs#Unprivileged_.28public.29_routes it looks like I don't have access to much of the REST API; only privileged people can access them. Also, the iCal feed I am trying to get seems to only be available from the SVC API.

> But since this is a case of one person exploiting a quirk in the system... it's probably not a huge drama. And it is one that I hope will be closed in the future ;).

Haha. I'm proud of myself for being able to figure out how to connect my books' due dates with my Google calendar, but I'm not proud AT ALL of putting my password in the url... but you guys left me no other choice!
Comment 8 David Cook 2021-01-05 01:24:58 UTC
(In reply to Nico Bako from comment #7)
> I'm thinking about how GitHub has "personal access tokens" 
> 
> https://docs.github.com/en/free-pro-team@latest/github/authenticating-to-
> github/creating-a-personal-access-token
> 
> But that might be too complicated to implement, and probably unnecessary for
> a library system.
> 

I often think of those as "application specific passwords" but that's just Google's word for it. 

It wouldn't really be that complicated, but I don't think it's on anyone's priority list. As you say, for a library system, there probably aren't that many library users who would want/need access to any kind of API.

> > Koha already uses short-lived API tokens using OAuth2 for its HTTP API.
> 
> I actually just checked this out, and I think you are referring to the
> REST-API instead of the SVC-API. I have tried using the REST-API, but I
> continue to get `{"error",:"Authentication failure."}`. Either I'm doing
> something wrong, or I just don't have access to some of the API endpoints.
> According to this page:
> https://wiki.koha-community.org/wiki/REST_api_RFCs#Unprivileged_.28public.
> 29_routes it looks like I don't have access to much of the REST API; only
> privileged people can access them. Also, the iCal feed I am trying to get
> seems to only be available from the SVC API.
> 

Yes, the API is mostly for privileged users. The REST API wouldn't work for your iCal feed either, since it uses either OAuth2, Basic Auth, or Cookie auth. I really don't see any other option than auth via URL parameters for your use case.

> Haha. I'm proud of myself for being able to figure out how to connect my
> books' due dates with my Google calendar, but I'm not proud AT ALL of
> putting my password in the url... but you guys left me no other choice!

Haha. It was very clever. I'll send an email out to people to see if anyone is willing to pick up this work. There are easier and harder ways of doing it, so maybe someone will look at doing an easier version.
Comment 9 David Cook 2021-01-05 01:41:01 UTC
Actually, Nico, I assume that the following is your website?

https://nicobako.github.io/

If you do want to play around with Koha, try out the following:
https://gitlab.com/koha-community/koha-testing-docker

Once you've explored that, you can look at the following for contributing your own code:
https://wiki.koha-community.org/wiki/Git_bz_configuration#Using_git-bz

You can look at the following for Koha Plugin development too:
https://wiki.koha-community.org/wiki/Koha_plugins

You can always join the OFTC #koha IRC channel or sign up to the koha-devel listserv as well to connect with Koha developers:

https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel

--

In other words, you could always work on this feature yourself. I'd be happy to review and test it. 

It looks like your library upgrades regularly, so I imagine that the feature could make its way back to your library fairly quickly, depending on the release maintainer.

An easy way of doing this feature could be to make use of the "borrower_attributes" table to store a "personal access token". Then all you'd need to do is update opac-ics.pl to consume it via a URL parameter and update opac-user.pl to provide an interface for you to generate your own "personal access token".
Comment 10 Nico Bako 2021-01-05 17:13:29 UTC
> Actually, Nico, I assume that the following is your website?
> 
> https://nicobako.github.io/

Yeah, that's me. The website is still very much a work in progress... so no judging please. This is also my website too: 

https://nicobako.pythonanywhere.com/ 

which is also very much a work in progress. I'm pretty new to web development stuff, and do nearly all of my programming in Python.

> In other words, you could always work on this feature yourself. I'd be happy to review and test it. 

Haha, yeah, I guess I could... I'm not going to make any promises of contributing to Koha (my life, just like most people's, is pretty busy...), but I will take a look at those documents and see where the wind takes me. Also, just like most people, I'm better at complaining about bugs/features than fixing them...

I do really appreciate the quick responses. I will definitely take a look at those links and see if contributing to Koha is something that both peeks my interests as a programmer and would fit into my schedule.
Comment 11 David Cook 2021-01-05 22:16:22 UTC
(In reply to Nico Bako from comment #10)
> Yeah, that's me. The website is still very much a work in progress... so no
> judging please. This is also my website too: 
> 
> https://nicobako.pythonanywhere.com/ 
> 
> which is also very much a work in progress. I'm pretty new to web
> development stuff, and do nearly all of my programming in Python.
 
We all were new at some point! I started off with PHP and now I write whatever I need/want to write. Once you're familiar with one language, it becomes pretty easy to learn another. 

>
> Haha, yeah, I guess I could... I'm not going to make any promises of
> contributing to Koha (my life, just like most people's, is pretty busy...),
> but I will take a look at those documents and see where the wind takes me.
> Also, just like most people, I'm better at complaining about bugs/features
> than fixing them...
> 
> I do really appreciate the quick responses. I will definitely take a look at
> those links and see if contributing to Koha is something that both peeks my
> interests as a programmer and would fit into my schedule.

Sounds good to me. I figured that I'd give you the opportunity to take a look at it. I'll get in touch with folks to see if anyone else wants to work on it too. I already have a number of things I'm working on, but I do find the idea interesting.
Comment 12 David Cook 2021-04-19 00:20:47 UTC
With the pushing of Bug 21325, the days for your calendar integration are numbered.

I still think what you've done is a great idea overall.
Comment 13 David Cook 2021-04-19 00:27:19 UTC
Tell you what... I'm inspired by your creativity and drive, Nico. I'm going to see about whipping up a quick patch to try and get the ball rolling here. 

Based on the comments on Bug 5456, we might find other people are interested after all.
Comment 14 Nico Bako 2021-04-19 02:06:35 UTC
Haha, I am actually looking forward to the day when passing user id and password in the url will no longer work. It's pretty insecure...

That being said, my iCal feed hasn't updated in quite some time, so perhaps these changes you are referring to have already taken place?

Also, I'm sorry I haven't been able to get involved in the koha project at all; life is quite busy, as I'm sure yours is too.

But, i really appreciate and admire all the hard work you do for this open source project. If ever I decide to get involved with and contribute to a large project, I will be sure to look into contributing to koha! So far I have been really pleased with your quick communication and your commitment to the project.
Comment 15 David Cook 2021-04-19 04:07:07 UTC
(In reply to Nico Bako from comment #14)
> Haha, I am actually looking forward to the day when passing user id and
> password in the url will no longer work. It's pretty insecure...
> 
> That being said, my iCal feed hasn't updated in quite some time, so perhaps
> these changes you are referring to have already taken place?
> 

Nah, they were just added to the master branch over the weekend. Unless the vendor for that system rolled it out faster.

> Also, I'm sorry I haven't been able to get involved in the koha project at
> all; life is quite busy, as I'm sure yours is too.
> 

Many of us get paid to work on Koha, so that helps a lot. I know I haven't had any free time of my own for it either. 

> But, i really appreciate and admire all the hard work you do for this open
> source project. If ever I decide to get involved with and contribute to a
> large project, I will be sure to look into contributing to koha! So far I
> have been really pleased with your quick communication and your commitment
> to the project.

Aw thanks. Authentication and authorization are passions of mine, so that helps make time for them.
Comment 16 David Cook 2021-04-19 07:04:23 UTC
Created attachment 119833 [details] [review]
Bug 27305: Use low privilege tokens to enable authenticated iCal feed

With the push of Bug 21325, it is no longer possible to authenticate
via a GET request using username and password. While this is an
improvement in security, it does mean that calendars like
Google Calendar cannot consume private iCal feeds from Koha.

This patch allows the autogeneration of unique tokens for users
so that they can access their iCal feeds without their username/password.

These tokens are pre-authenticated in opac-ics.pl and then passed
to C4::Auth::checkauth() via get_template_and_user() for verification
thanks to two very small changes in C4::Auth.

Test plan:
1) Apply patch
2) Upgrade database (koha-upgrade-schema koha-dev)
3) Checkout item to patron (e.g. 39999000001310 to koha patron)
4) Log into /cgi-bin/koha/opac-user.pl
5) Right click iCal and copy link (e.g.
http://localhost:8080/cgi-bin/koha/opac-ics.pl?token=facb63f231ecba45bc70aadedfdd045b)
6) Log out of OPAC
7) Go to iCal link
http://localhost:8080/cgi-bin/koha/opac-ics.pl?token=facb63f231ecba45bc70aadedfdd045b
8) Observe that iCal download is performed
9) Go to OPAC home page (e.g. http://localhost:8080/cgi-bin/koha/opac-main.pl)
10) Note that you are not logged into the OPAC
(FYI this is because opac-ics.pl does not send back a cookie. If it did, then
you would be logged into the OPAC.)
Comment 17 David Cook 2021-04-19 07:13:10 UTC
(As a side note to people who come here, I also have a local customization that allows you to provide an arbitrary auth module with a simple API that can handle login and logout. It's called via checkauth, so it's invoked per-script rather than globally. But that's a conversation for another time...)
Comment 18 David Cook 2021-04-19 07:14:28 UTC
(Something else to keep in mind, this is an opportunity to play with re-vamping authentication a bit without breaking anything else, since it's a specific token for a specific page.)
Comment 19 Sally 2022-05-10 13:41:39 UTC
Sorry, patch no longer applies.
Comment 20 David Cook 2022-05-11 00:25:44 UTC
(In reply to Sally from comment #19)
> Sorry, patch no longer applies.

Thanks for testing :).

This patch needs an overhaul and I'm not sure there's enough community interest in it to advance anyway, unfortunately.
Comment 21 Michal Denar 2022-05-11 05:57:51 UTC
Hi,
I like the idea. Some time ago I wondered if it would be possible to attach an iCal file to notification messages. But the feed is easier for the user. It would be great to add the ability to manage iCal feeds via the API. For libraries that use other OPAC solutions (like VuFind). Actually, it would be enough to generate/delete a token this way. It would also be great to add the expiration date of the reader account to the feed. From my point of view, this feature has a lot of potential. I'm not a developer, but I can offer testing.