[Koha-bugs] [Bug 27305] iCal feed for circulation issues

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Mon Jan 4 00:20:02 CET 2021


https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27305

--- Comment #6 from David Cook <dcook at prosentient.com.au> ---
(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 ;).

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are watching all bug changes.


More information about the Koha-bugs mailing list