Jump to content

Recommended Posts

@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

Share this post


Link to post

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?

Share this post


Link to post

 

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 by deanishe

Share this post


Link to post

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'

Share this post


Link to post

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

 

Share this post


Link to post
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.

 

Share this post


Link to post
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.

Share this post


Link to post
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 by xilopaint

Share this post


Link to post
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.

 

Share this post


Link to post
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!
 
 
Screen Shot 2018-12-25 at 9.56.15 PM.png
 
Screen Shot 2018-12-25 at 9.56.40 PM.png
 

Screen Shot 2018-12-25 at 9.56.15 PM.png

 

Screen Shot 2018-12-25 at 9.57.39 PM.png

cleardot.gif

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post
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?

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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?

Share this post


Link to post
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

Share this post


Link to post
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 by deanishe

Share this post


Link to post
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.

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...