What URIs should I use when using the plugin api to work with Google Calendar API using google's OAUTH2 system #5052
Replies: 3 comments 3 replies
-
|
Google's hint for Authorized Javascript Origins: The HTTP origins that host your web application. This value can't contain wildcards or paths. If you use a port other than 80, you must specify it. For example: https://example.com:8080 Google's hint for Authorized redirect URIs: Users will be redirected to this path after they have authenticated with Google. The path will be appended with the authorization code for access, and must have a protocol. It can’t contain URL fragments, relative paths, or wildcards, and can’t be a public IP address. And here's a description of how it works for web applications: https://developers.google.com/identity/protocols/oauth2/javascript-implicit-flow#creatingcred Am I right to think that Super Productivity and Super Productivity plugins can be considered/treated as client side web applications running locally instead of full fledged node.js applications (which won't have URIs listening): https://developers.google.com/identity/protocols/oauth2/native-app#creatingcred? |
Beta Was this translation helpful? Give feedback.
-
|
That is a very cool idea! Unfortunately the whole authentication part is quite complicated as you already figured out, since we ideally want it to work in the web and desktop and mobile. Using the gapi (https://github.com/google/google-api-javascript-client) might help with that at least on the web. Until a couple of years ago there was google drive as a sync provider, but I had to get rid of it due to changes in the authentication mechanisms. This might have changed again, but I don't know tbh. Its a rather complicated subject and my knowledge is quite dated and there are several avenues you can go down. The "easiest" to make it work cross platform is probably to bundle the plugin with another backend web application that handles the authentication stuff. We could also try to work with the urls like superproductivity://google-auth which would require changes to the app (which I could help with), but it is all rather complicated even if we took out the plugin context completely. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, Johannes. So, I think there are two ways to work with Google's OAUTH2 apis. One is as a web page that's being hosted and served by something like the http-server npm module (this is likely the method I'd be using for the web app though): https://developers.google.com/workspace/calendar/api/quickstart/js). The other, which I think will be applicable to the desktop and mobile apps at least is to use google's javascript api and authentication libraries, as referenced here: https://developers.google.com/workspace/calendar/api/quickstart/nodejs. I wonder if these libraries will work with the hosted web app too. So I actually loosely followed the documentation from the obsidian google calendar plugin (the pdf here: https://yukigasai.github.io/obsidian-google-calendar/Setup) to set up the OAuth2 and the google calendar api environment on the Google Cloud Console (I left it as testing to make the authentication easier). Then I saved and ran the javascript quick start code linked above after I installed and launched the http-server npm module to serve the webpage (https://github.com/http-party/http-server). Setting the URIs to 127.0.0.1:8558 and making sure http-server was serving the pages at that port worked great. So I think my plan should work in theory even if I don't see anything in the package.json file that there's anything like http-server that's listening at a specified port. I should add that my background's is to be a scientific programmer, with an extensive background in R and python. So this is going to be my first foray into Javascript, Typescript, node.js, and the Angular framework and I'm looking forward to learning all of this. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi, I'm trying to create a plugin (that at least as a prototype) will enable the user to schedule tasks as calendar events on google calendars (for now, I'm thinking about having each project correspond to a specific calendar (and maybe using secondary calendars, whatever they are ... they seem to require fewer permissions which is always good). Since underlying SuperProductivity is more or less a Javascript/Typescript web app, I set up web app client ID for my test system, which requires the following two URIs: Authorized JavaScript origins URI and Authorized redirect URIs (the URI to return to after the authentication is complete).
So my main question is what should these URIs be set to for it to work via the plugin system? Should the origin be 127.0.0.1:port for the local applications (and what port does the app listen in on?) and app.super-productivity.com for the explicit webapp? And for the redirect URIs, should they be 127.0.0.1:port/#/plugins/mypluginname/index(or authenticate instead of index) and app.super-productivity.com/#/plugins/mypluginname/index? Am I wrong about the javascript/typescript web app assumption for the desktop and android apps?
I don't know if this plugin will see the light of day outside of my own use (I think this sort of capability and maintenance of app verification with Google is probably better through base Super Productivity rather than through a plugin. I don't know how verification of the plugin without verification of the full super productivity application would work. Since it's still in testing mode, I don't have to verify it with Google, and so I can make it work for my needs. I'm hoping to create more things via this plugin, and that functionality I think can be separated from this Google Calendar (and later Outlook 365 and iCloud CalDav) functionality.
Beta Was this translation helpful? Give feedback.
All reactions