Skip to content

Conversation

@duester
Copy link
Contributor

@duester duester commented Jun 5, 2021

#11

Copy link
Owner

@reibitto reibitto left a 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.

image

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.

@reibitto
Copy link
Owner

reibitto commented Jun 6, 2021

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.

@duester
Copy link
Contributor Author

duester commented Jun 7, 2021

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 :)
I'll add a comment if I build something useful.

@duester
Copy link
Contributor Author

duester commented Jun 8, 2021

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 ;)

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants