Vero Posted May 19, 2017 Share Posted May 19, 2017 @magnotti The Python-based framework used in some Alfred workflows on macOS Sierra causes the high CPU usage you're seeing. Take a look at this thread for the latest update from the workflow creator. He's provided a workflow you can run, which will fix the issue in all affected workflows:https://www.alfredforum.com/topic/10193-python-fix-how-to-fix-python-workflows-hanging-alfred-on-sierra/ Cheers, Vero magnotti and jbrains 2 Link to comment
jzadra Posted April 12, 2018 Share Posted April 12, 2018 When logging in, it wants to give access to all my files to "Alfred Drive Workflow". Does this open my drive security to a 3rd party? I see that a CLIENT_ID and CLIENT_SECRET is predifined in the python script. Is there any documentation on who gains access and security in general using this workflow? Link to comment
deanishe Posted April 12, 2018 Share Posted April 12, 2018 (edited) 15 minutes ago, jzadra said: Does this open my drive security to a 3rd party? No, it gives the workflow you're using access to your Google Drive. 15 minutes ago, jzadra said: Is there any documentation on who gains access and security in general using this workflow? The only person who gains access is you. The workflow uses Google's standard OAuth 2.0 authentication. It is very well documented online. As for how securely the workflow handles the access tokens, the workflow's source code is the definitive "documentation". From my reading, the workflow handles your access tokens perfectly by storing them in Keychain. Edited April 12, 2018 by deanishe jzadra 1 Link to comment
jzadra Posted April 13, 2018 Share Posted April 13, 2018 Thanks. I was curious about lines 14 and 15 in the google-drive.rb file that have static client info set. Who's ID is that? CLIENT_ID = '978117856621-tvpnqtr02b8u0bgnh75sqb1loq1f5527.apps.googleusercontent.com' CLIENT_SECRET = 'rty2NIATZfWFWSDX-XPs2usX' Link to comment
dfay Posted April 13, 2018 Share Posted April 13, 2018 The workflow’s. See step 1 here: https://developers.google.com/identity/protocols/OAuth2 Link to comment
xilopaint Posted April 13, 2018 Share Posted April 13, 2018 I have poor knowledge on OAuth but found this in an article : Quote If the developer is creating a “public” app (a mobile or single-page app), then you should not issue a client_secret to the app at all. This is the only way to ensure the developer won’t accidentally include it in their application. Quote It is critical that developers never include their client_secret in public (mobile or browser-based) apps. To help developers avoid accidentally doing this, it’s best to make the client secret visually different from the ID. This way when developers copy and paste the ID and secret, it is easy to recognize which is which. Usually using a longer string for the secret is a good way to indicate this, or prefixing the secret with “secret” or “private”. Link to comment
deanishe Posted April 13, 2018 Share Posted April 13, 2018 1 hour ago, jzadra said: Thanks. I was curious about lines 14 and 15 in the google-drive.rb file that have static client info set. Who's ID is that? CLIENT_ID = '978117856621-tvpnqtr02b8u0bgnh75sqb1loq1f5527.apps.googleusercontent.com' CLIENT_SECRET = 'rty2NIATZfWFWSDX-XPs2usX' That identifies the client application (in this case, the workflow) to Google. The whole point of OAuth is that you can grant individual applications and services partial access to your stuff on Google without ever giving them your password, and then withdraw access for an individual application without having to change your password. The client ID and secret simply serve to identify the application to Google, so that the access rights can be associated specifically with that app. That's what allows you to revoke access for a specific application without breaking everything else. Link to comment
deanishe Posted April 13, 2018 Share Posted April 13, 2018 29 minutes ago, xilopaint said: It is critical that developers never include their client_secret in public (mobile or browser-based) apps I'm not sure it's actually critical (from my understanding, OAuth2 threw out the OAuth1 requirement that access tokens be bound to the client ID, which if true, makes the client ID a bit of a joke), but certainly Google does not like client IDs and secrets turning up in public repos. If/when they find out that the workflow's client ID and secret are stored publicly on GitHub, chances are good that they'll invalidate the ID. Having them in the zipped .alfredworkflow file is technically no more secure, but far less likely to be noticed, imo. Link to comment
xilopaint Posted April 14, 2018 Share Posted April 14, 2018 (edited) On 4/13/2018 at 8:37 PM, deanishe said: I'm not sure it's actually critical (from my understanding, OAuth2 threw out the OAuth1 requirement that access tokens be bound to the client ID, which if true, makes the client ID a bit of a joke), but certainly Google does not like client IDs and secrets turning up in public repos. So what is the best practice? Edited December 26, 2019 by xilopaint Link to comment
deanishe Posted April 14, 2018 Share Posted April 14, 2018 47 minutes ago, xilopaint said: So why is the best practice? You mean what is the best practice? Not sure, tbh. (At least, as far as "best practice" = "what Google wants".) I only have one (public) workflow that uses Google's APIs. The client ID and secret are excluded from the repo, but the compiled workflow contains them. In this case, the workflow is written in Go, so the ID and secret are contained in the binary, not as plaintext in a script in the .alfredworkflow ZIP file. Link to comment
xilopaint Posted April 14, 2018 Share Posted April 14, 2018 38 minutes ago, deanishe said: You mean what is the best practice? Yes, sure. Sorry for the typo. Link to comment
patriciodz Posted December 28, 2018 Share Posted December 28, 2018 I am running into a problem with this workflow. When I try to search for a file (d name of the file) it takes me to the sign up page and then a window says "Successfully connected to google drive" and then takes me in a loop to again sign up and allow Alfred to access the drive. I have attached screenshots of the sequence (below) Could you help me with this? Thank you in advance! Link to comment
mlondon Posted December 19, 2019 Share Posted December 19, 2019 Hi, I've updated this Workflow to the latest version. When I try to use it in Chrome for Mac, it asks me to: Choose an account to continue to Alfred Drive Workflow I select my current Google account. But then I get a message in the browser saying: Sign in with Google temporarily disabled for this app This app has not been verified yet by Google in order to use Google Sign In. Please advise. Thank you. Link to comment
deanishe Posted December 19, 2019 Share Posted December 19, 2019 7 hours ago, mlondon said: Sign in with Google temporarily disabled for this app This app has not been verified yet by Google in order to use Google Sign In. Google has changed the rules for signing in via OAuth. The new rules kinda make sense for web applications (i.e. where you're granting my server access to your stuff), but are ridiculous for software you're running locally, like workflows. Link to comment
AlexSchetinin Posted December 20, 2019 Share Posted December 20, 2019 On 12/19/2019 at 11:38 AM, deanishe said: Google has changed the rules for signing in via OAuth. The new rules kinda make sense for web applications (i.e. where you're granting my server access to your stuff), but are ridiculous for software you're running locally, like workflows. How to solve this problem? Link to comment
deanishe Posted December 20, 2019 Share Posted December 20, 2019 20 minutes ago, AlexSchetinin said: How to solve this problem? You'll have to wait for Google to verify the workflow… It's possible the author could move things along by jumping through Google's hoops, but like the message says, Google has disabled it. Link to comment
deanishe Posted December 20, 2019 Share Posted December 20, 2019 I just checked my Google Calendar workflow (I refused to jump through their hoops), and you get a big, scary warning, but it still lets you sign in. So there might be an actual problem with this workflow, possibly due to its OAuth secret being in the source code (as mentioned earlier in the thread). If you're desperate to use it, you could get your own OAuth ID+secret from Google and edit your copy of the workflow to use yours instead. AlexSchetinin 1 Link to comment
ixium Posted December 26, 2019 Share Posted December 26, 2019 Hey Deanishe, any suggestions on how to do that? I use this workflow constantly and am missing it! Link to comment
ionstorm Posted January 6, 2020 Share Posted January 6, 2020 If you guys use Google Drive File Stream, you can search it like you search Google Drive files like you search for any regular file in Alfred. Link to comment
deanishe Posted January 11, 2020 Share Posted January 11, 2020 I just got another snotty email from Google saying my workflow is now locked down because I didn't follow their silly instructions. I'd guess the same thing has happened with this workflow, and Google is now rejecting authorisation requests for it. Link to comment
xilopaint Posted January 11, 2020 Share Posted January 11, 2020 This workflow is working normally for me. Link to comment
Xage Posted January 17, 2020 Share Posted January 17, 2020 It appears if you had this authenticated before Google made this change, this workflow will still work. I recently tried to get this on a MacBook air and i get the error message. Works perfectly fine on my MacBook Pro. @deanishe How do you get your own OAuth ID+secret from Google? Link to comment
Terminal Posted January 17, 2020 Share Posted January 17, 2020 46 minutes ago, Xage said: It appears if you had this authenticated before Google made this change, this workflow will still work. I recently tried to get this on a MacBook air and i get the error message. Works perfectly fine on my MacBook Pro. @deanishe How do you get your own OAuth ID+secret from Google? I think this would be the right way. https://developers.google.com/identity/protocols/OAuth2 Link to comment
deanishe Posted January 17, 2020 Share Posted January 17, 2020 (edited) 6 hours ago, Xage said: It appears if you had this authenticated before Google made this change, this workflow will still work. That is correct. On the warning page, you should see an "Advanced" link at the bottom. If you click on that, you can still click through and authorise the workflow. 6 hours ago, Xage said: How do you get your own OAuth ID+secret from Google? Via the developer console. It's a bit complicated, though. I tried to follow the verification instructions, but Google are being complete idiots. My workflow was rejected because: We detected the following issue(s): • Homepage contains "google" in the domain ◦ homepage_url: https://www.deanishe.net/alfred-gcal-workflow/ I'll wait a few more days to see if Google can get it together, and if not, I'll post detailed instructions on the repo. I'll also have to update the workflow to read credentials from an external file. Edited January 17, 2020 by deanishe Link to comment
Xage Posted January 18, 2020 Share Posted January 18, 2020 14 hours ago, deanishe said: That is correct. On the warning page, you should see an "Advanced" link at the bottom. If you click on that, you can still click through and authorise the workflow. I don't have this "Advance" link. When I use the command "D ", Safari opens the google account select screen. After selecting the account I want, i get the "temporary disabled" screen. Is the "Advance" link on one of those pages? If so, its not showing up for me. Link to comment
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now