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

Link to comment
  • 10 months later...

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

 

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

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

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
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
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
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
Link to comment
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
  • 8 months later...
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
Link to comment
  • 11 months later...

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

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.

Link to comment
  • 2 weeks later...

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

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
×
×
  • Create New...