-
-
Notifications
You must be signed in to change notification settings - Fork 136
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[calendar3-cli] Insufficient authentication scopes for calendar ids with a # #308
Comments
Thank for trying the CLI, and I love that I traced the parameter (containing the '#') to this line which is where the URL is parsed back from a string. There I believe the truncation happens. When looking at how this calendar ID is used, it gives me this:
So apparently for this to work the calendar ID must be escaped in some way to be valid within the URLs path. Is this something you could try locally to see if that works? If so, we could make this work for all APIs. |
I don't have any Rust experience, but I googled the top Rust web framework, which seems to be Rocket, and I checked how it handles it - via the https://rust-lang-nursery.github.io/rust-cookbook/encoding/strings.html But it might just be simpler to do a search and replace, |
@shaicoleman Great, that should do. Maybe you can try it yourself with a locally modified version of the crate (the patch section in the cargo manifest can be used to make that easy). If that's working, the code could then be integrated into the generator, and a simple find & replace should be fine at first if it fixes this issue and clearly is better than the status quo. |
I had a quick look, but I'm afraid tackling a new programming language isn't something I have the bandwidth for at the moment |
It seems like the
calendar3 events list
command doesn't handle correctly calendar IDs containing a hashI tried running mitmproxy to see what's happening, and it's trying to access this URL:
https://www.googleapis.com/calendar/v3/calendars/en-gb.irish?alt=json
.It seems that it's truncating everything after the hash. The workaround is to percent encode the hash:
The text was updated successfully, but these errors were encountered: