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
58 minutes ago, 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 why is the best practice?

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

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×