-
Notifications
You must be signed in to change notification settings - Fork 13
Add CalendarCommand #208
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
base: master
Are you sure you want to change the base?
Add CalendarCommand #208
Conversation
reibitto
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR!
I'm not too familiar with authentication for Google services using OAuth. I checked hoping they had a simple API key method (like they do with YouTube where I use it in one of my other projects). Unfortunately it looks like that's not available for Google Calendar 😥
I guess we're forced to use OAuth, which means I have to register the app, create a logo, and get approved I think. Sounds a bit painful, but if it needs to be done then I guess I'll have to do it. I mean, I think we can use a test account in the meantime but it's more limited (quotas and so on).
I see you chose a "service account", but is that appropriate for this type of app? The fact that the credentials and private key are committed indicates to me that this is probably not the right one. It looks like a service account is more for server-server usage.
For an app like this one, we probably want an OAuth client ID. So no sensitive information is stored in the app/repo itself. Also, I think this means we need a setup task where when a user of Command Center uses the calendar feature for the first time a browser window will pop up where Google's "This app is requesting permission to access your calendar" OAuth screen comes up. Then once you click "Allow" it should save that information locally and continue as normal.
But I think this means I finally need to do this persistent storage ticket: #95
because it sounds like it's a prerequisite for this PR.
Honestly, I don't know if I got all this right. I've never done this kind of integration before. I'm just basing this on some assumptions and how I've seen other desktop apps behave when they ask for OAuth permissions. I'd need to do a little more research to know for sure.
If what I'm saying is true, then can you eventually look into how to do that OAuth permission popup? I wonder if Google's oauth lib takes care of most of that for you. I don't know as I've never used it.
No rush though. I'll have to first do that persistent storage feature, which might take me a little while to get to and complete.
|
I think once you open the browser window, there will be a callback/redirect indicating whether the user clicked "Allow" or "Decline". If they clicked "Allow", then I think Google will return an access token + refresh token. That's the information that needs to be stored locally. Then each subsequent request will use those tokens. At least that's how I understand it. I may have gotten some details wrong though. |
|
Hi! Thank you for your feedback! Yes, the authorization part of the program was quite difficult. The official docu didn't give me enough insight. I've collected infos from many sources and finally came up with the current solution. You're right, it's not ideal at all, because of needing to commit the credentials to the repository. I just wanted to implement the actual logic, so that now, as it's finished, I'm going to dig into the OAuth ID authorization. I've also never done it before, so let's see if I will be successful :) |
|
Now I've remembered why I decided not to go the OAuth way at first. Yesterday I looked into the documentation again - they have too much pages with hundreds of hyperlinks. Now I'm a bit lost :) That said, I could not find any useful code example so far. So it won't be that easy, I guess. But I'm optimistic ;) |

#11