Migrate your OAuth out-of-band flow to an alternative method
VDP07 opened this issue · 25 comments
Hi,
I've got email with the above title and say that this assistant relay will be effected by this. Any suggestion on this matter?
Same here.
Hope we won't lose the Google broadcast functionality. It is so much better than usual tts, in that it just pauses whatever is going on the actual speaker..
Me too. I know you aren't supporting this any more, but certainly we'd appreciate either a fix or being pointed to how to fix ourselves or some replacement option. If I Google how to use Google Broadcasts, all I see is this option over and over.
Anyone have an update they can share? Worried this will bomb out in a few months and leave everyone stranded
Also concerned here. Have figured out I can replace this with Node Red - but can't seem to get the voice I want. Would prefer to stay with this which has worked perfectly.
What version are you currently running? The latest version uses an Oauth2 method for authentication which should still be good from what I am reading online. I know I didn't receive such a message for my Assistant Relay instance and I don't see any warnings at all when I look at the project in the Cloud Console.
I am on v3.3.2b according to the About page. Is there something newer than this?
That's odd. When you set it up originally, what "client" did you pick when you set up your oauth authentication? If you selected "other" that might be why you're getting the message. I selected "Desktop". "Other" isn't an allowable choice anymore when setting up Oauth2 with Google.
This is the issue i see. The Google side isn't documented properly for the assistant requirements. You're pointed to a Google instruction page and i had problems following this last year as I've never created a project. Lots of YouTube and Google searches to get it up and running... And not stop after a week
I last set this up last December when I moved it to a new server - I can't exactly recall all of the options but when I go to the Credentials page it lists it as of type "Web Application." It is also trying to get me to complete an OAuth Consent Screen that I don't remember before - something has changed. That screen wants me to select "External" where it says it will only run in Testing Mode - it says that "Internal" is only for Google Workspace users. Color me confused.
When you go to the Oauth Consent Screen page, linked to on the left hand menu under Credentials, all you have to enter is your app name and your email address. Since you are the only one using your app, you are the only one who is ever going to see the consent screen. And the fact that the app is unverified only really matters to folks who are distributing their apps to the public. Do you care that your app is unverified? Of course not. So, you can put it into production with the warning that the app is unverified without a problem. If you were distributing the app to the public this would be bad (I would never approve an app I didn't write that was unverified) but you're not sending your app to the public.
Once you do that you have to move your app to production. I will go through and create a whole new project from start and grab all the screenshots since the screens have changed quite a bit since the last time I grabbed them. I will let you know what I will let you know if I am able to find the correct settings you need to avoid the expiration of those older Oauth2 methods. Won't have time for a couple days, so stay tuned.
That would be extremely helpful. Thanks so much
I have created a PDF that should walk you through it step by step. If you have trouble, let me know:
https://github.com/ryancasler/assistant-relay/blob/master/Create%20Cloud%20Proejct.pdf
(Also, I think I've hidden all my personal info but if you see any, please let me know that too.)
As long as you are updating the security information there is one thing you might want to add that I did not originally understand when setting it up. That is the security is only between Assistant Relay and Google. ANYONE with access to port 3000 on the system where Assistant Relay is running can execute arbitrary commands for any of the authorized users in Google Assistant such as making calls, sending/reading email, etc. So it is very important not to allow public access to that port.
Yes, absolutely. You do not want to leave Assistant Relay public facing. No port forwarding or the like. All requests should come from other devices on your LAN. Mine come from my Hubitat.
Also concerned here. Have figured out I can replace this with Node Red - but can't seem to get the voice I want. Would prefer to stay with this which has worked perfectly.
Sorry to butt in - could you please elaborate on how you made this work using NodeRed?
I have created a PDF that should walk you through it step by step. If you have trouble, let me know: https://github.com/ryancasler/assistant-relay/blob/master/Create%20Cloud%20Proejct.pdf
(Also, I think I've hidden all my personal info but if you see any, please let me know that too.)
Thank you so much. Finally got the time to do this and seems to work!. Take care
From what I have read, as long as your redirect URL doesn't use "localhost" your OAUTH flow should not be affected. I removed my old OAUTH files from my project in the console and everything is still working. I wasn't sure that everything was going to work correctly but it turned out that the problem I was having was with the Oauth json file. It seems that once you use that file to activate one user, you can't use it to activate another. You would have to download another copy of the JSON file. As long as this is working for other folks, I will re-publish that fix that I removed.
I think I have a method that will work to get this running without any code changes at all. And it has to do with how you create your Oauth Client. Instead of choosing Desktop, choose "Web Application". You will then be presented with a screen to add your redirect URI. Simply enter https:.//www.example.com and click create. This will create a json file for you to download that will not use localhost as the redirect URI, so it should still work.
Once you go to add your user using that JSON file, you will eventually get
to an example.com page where the address will contain a code:
(don't worry, that's not the real one, I subbed in a lot of fake
characters)
just copy everything after "code=" to "&scope". So, mine would be:
4/0AdQt8q474dfdydghdsdbdbtRrzq0QC_lObsRrsdwa4yXIssdfvxkgF8zHrvrtyrrhdyz4EumCwwett433g
Use that to enter the code into GAR to authorize the user.
I used this method a while ago and everything is still working so far.
It is now after Oct 3rd, and it is still working. So, we should be good. PHEW!