franc6 / ics_calendar

Provides an ICS (icalendar) platform for the Home Assistant calendar
Apache License 2.0
151 stars 23 forks source link

URL from UI Configuration gets saved differently #169

Open bobbolous opened 2 months ago

bobbolous commented 2 months ago

I have a ICS calendar with a URL like this (removed some information) https://<thisWasRemoved>/api/ical?street=L%C3%A4ngestrasse&streetnr=123

after entering this into the UI I get an error log, that this URL is not reachable. https://<thisWasRemoved>/api/ical?street=L%25C3%25A4ngestrasse&streetnr=123

As you see there was a "25" added ("...L%25C..." instead of "...L%C..."). Background: originally this is a streetname that includes a german "ä".

I am running on 5.0.3.

franc6 commented 2 months ago

When entering URLs in the UI, please enter it using UTF-8 characters. The UI will encode the characters properly for the URL.

This is in my TODO list to update, so users can enter the URL either way, but it’s not there yet. :(

bobbolous commented 2 months ago

Thanks for your fast response. As I understand it the URL I am entering is already UTF-8. The "ä" was merely as a background information. The URL https://<thisWasRemoved>/api/ical?street=L%C3%A4ngestrasse&streetnr=123 contains the percent notation of "ä" in UTF-8 (%C3%A4).

I think the % in the URL is rewritten to %25 as this is the percent notation of %. https://en.wikipedia.org/wiki/Percent-encoding#Percent_character

troed commented 2 months ago

I'm seeing this as well with a URL from Proton Calendar. % is being rewritten.

franc6 commented 2 months ago

I meant to enter it as UTF-8 as opposed to entering it already URL-encoded. For your case, @bobbolous, that would mean https://&lt;thisWasRemoved&gt;/api/ical?street=Längestrasse&streetnr=123

There was a request (via PR #133) back in June to allow entering emojis directly instead of URL encoding them. This directly conflicts with what you're entering, and while there is a simple way around that, the simple fix might not match well with a good fix, so my current compromise is to keep the conflict until a proper fix is provided. See also TODO.md. I know it could be a while, but I really hope to get to it sooner than it took 5.0 to be released, since all of the 5.x items really, really annoy me. And the bugs that annoy me tend to get fixed faster. :)

Please note if this conflict is one you don't want to deal with, look in config_flow.py, search for "safe", and change safe=":/?&=" to be safe=":/?&=%". That's the simple fix.

troed commented 2 months ago

Thank you for the workaround - it works well. I do think asking users to reverse URL-encoding they get from their calendar services is a bit too much to ask but I understand your conflicting requests :D

franc6 commented 2 months ago

@troed I don’t disagree with you. :(. But thanks for your understanding. I greatly appreciate it.

bobbolous commented 2 months ago

Thanks for the great support! Using https://<thisWasRemoved>/api/ical?street=Längestrasse&streetnr=123 worked.

LPirro commented 1 month ago

@franc6 I have a similar issue setting up my calendar from the UI:

I have this calendar URL from Google (I obfuscated the key with x below but they are only letters and numbers, not special characters).

Correct URL: https://calendar.google.com/calendar/ical/username%40gmail.com/private-xxxxxxxxxxxxxxxxxxxxxx/basic.ics

URL added by the plugin: https://calendar.google.com/calendar/ical/username%2540gmail.com/private-xxxxxxxxxxxxxxxxxxxxxx/basic.ics

you can see that the error is here username%2540 (25 gets added but it's not present in the correct url).

Thanks

franc6 commented 1 month ago

@LPirro For now, you can replace %40 with @