Skip to content
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

Open
shaicoleman opened this issue Nov 27, 2021 · 4 comments

Comments

@shaicoleman
Copy link

shaicoleman commented Nov 27, 2021

It seems like the calendar3 events list command doesn't handle correctly calendar IDs containing a hash

$ calendar3 events list "en-gb.irish#[email protected]"
Bad Request (403): Request had insufficient authentication scopes.
    global: Insufficient Permission, insufficientPermissions

I 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:

$ calendar3 events list "en-gb.irish%[email protected]" | jq .kind
"calendar#events"
@Byron
Copy link
Owner

Byron commented Nov 28, 2021

Thank for trying the CLI, and I love that mitmproxy debug work, somehow I didn't think it was possible to intercept these calls.

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:

        let mut url = self.hub._base_url.clone() + "calendars/{calendarId}/events";

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.

@shaicoleman
Copy link
Author

shaicoleman commented Nov 29, 2021

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 percent-encoding crate.

rwf2/Rocket@3bf577d

https://rust-lang-nursery.github.io/rust-cookbook/encoding/strings.html

But it might just be simpler to do a search and replace, # => %23
# may be the only character that needs to be encoded

@Byron
Copy link
Owner

Byron commented Nov 29, 2021

@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.

@shaicoleman
Copy link
Author

shaicoleman commented Nov 30, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants