I created a new appengine project, which creates a default web app and associated client ID. When I try to use this client ID, I get "invalid client ID".
This looks like a bug in the cloud console.
To fix, I created an additional web app, which creates an additional client ID of the form 123456-randomness.apps.googleusercontent.com
The secondary client ID works.
When I go back and try the original client ID, that now works too.
Related
I'm trying to integrate Interactive live streaming in the React native app. It works fine with the temp token and console generated channel name, But in real-world example when the user goes for the live stream it will create its own channel so for this purpose, I use the NODEJS server to generate token with APP ID and APP CERTIFICATE and gets the token then I pass generated token JoinChannel.
this.state.token = TOKEN GENERATED FROM SERVER
this.state.channelName = I USE USER ID TO AS CHANNEL NAME (this is
the same name that I pass to the server while generating token)
this.state.userId = MONGO DB USER ID (this is the same id that I pass to the server while generating token)
this.state.channelName = this.state.userId = 612e77c536d8140016ee4ef2
await this._engine?.joinChannel(this.state.token, this.state.channelName, null, this.state.userid)
After that, I got nothing in CONSOLE and JoinChannelSuccess not fired.
Looks like a problem with your credentials. A common error can be setting the expiry time too low when generating the token using NodeJS. Another common error can be mixing the userId type, you can choose between userAccount or integer type. I'd suggest double checking all the values in both places.
I create a new database, and when I create a document and submit to this database from the web, I got an error in the console:
HTTP Web Server: IBM Notes Exception - The certificate table does not contain enough valid certificates to verify the public key of its owner.
But if I submit a document to another database in this server, I can save successfully. Where can I setup or need do some other step? When I open a form in this new database, I also got this error in a message box. I tried to change ACL for the new database but it did not work.
If you're getting this error while attempting HTTP access to a specific database, it probably means that there is something odd about the signature on one or more design elements in the database. I.e., the signature on the form, the query save agent, or some other design element was done with an id that doesn't share a common root certificate with the server.
Try using the Domino Administrator client to sign the database, either with the server id or with another id in the same organization.
Is there a way to change the OAuth2 client secret for our Google app without changing the client ID?
I would like to change the client secret as a security best practice (e.g. when one of our production sys admins leaves the company) without having to get all our clients to re-authorize our app.
All I've found on this forum is how to generate client IDs and secrets for new applications. From what I can see, the only option is to generate a new client ID and secret together, meaning any authorizations obtained with the old client ID are effectively useless.
Client id and Client secret are a pair, together they are used to create the Refresh token and access tokens that allow your application to access a users data. If you where to only change the client secret then the refresh token and access token generated wouldn't match the old one. But any way you can't just change one.
You can create a new client id and Client secret pair for your application and then delete the old one. But the draw back to this will be that any one that had previously given your application access to there data will be forced to reauthenticate because there current refresh token will no longer work.
While I applaud your sense of security and desire to protect your customers data. There is a fine line between annoying customers and protecting them. I wonder how big of a chance there is that this person actually stole a bunch of refresh tokens as well as the client id and Client secret for your application? I also wonder what kind of access your application has and what the damage your former employee could do with the information they may or may not have stolen. Will it be worth it for them to create a new application to use the refresh token and application credentials?
You need to judge if its worth bothering your customers and forcing them to reauthenticate your application every time someone leaves the company.
Josh from the AdWords team directed me to the "Return to original console" link in the bottom right corner. In that version of the console you are able to reset client secrets.
See https://groups.google.com/forum/#!topic/adwords-api/twf3O3fg1oA for the cross posting.
I am creating an app in ai2 that connects to one of my fusion tables as a high score datastore.
If I use traditional Oauth2 flow then each user would be presented with an oauth login for their fusiontable, which is not what I want.
I have set up a
Client ID for Android application
in the google developer console which gave me
Client ID xxxxxxxxx.apps.googleusercontent.com
Redirect URIs
urn:xxx:xxx:xxx
http://localhost
Package name appinventor.ai_xxxxxxxx.xxxxxxxx
Certificate fingerprint (SHA1) 12:34:56 etc
Deep linking Disabled
What I want is for my app to connect to my fusiontable using my credentials regardless of which device or which user. How do I do that?
Thanks
This document is a very simple and straight-forward guide to creating a fusion table for your app.
https://docs.google.com/document/d/1HifuZqz5xu0KPS-e4oUv-t-nQoUQ8VMNyh_y6OjZkc0/pub
Steps:
First, you have to create a project at console.developers.google.com.
Then go to the API manager in the menu. Search for and enable the fusion tables API.
Now create a service account key. You may have to look in the credentials menu for this setting. Choose "enable Google apps-wide delegation". A service account is a localized email address that your app can use when you share the fusion table with that account. It provides more security than the anyone with the link can edit setting.
Now go to New Credentials > Service account key. Select P12, and the file will automatically download. If the name of the file has spaces, remove them.
Next, create a google fusion table.
Now share the table with the service email you created. Set the permission to Can Edit. Uncheck the notify box and hit Share.
Now, go to App Inventor. You need:
Your Service Account Email address (also called service account ID)
Service Account key file (.p12)
Fusion Table ID code (don't worry about this yet)
First, upload the key file.
In the fusion tables component property menu, set the KeyFile property to the key file. Copy the email address you created earlier and paste it in the ServiceAccountEmail property. Check the Use Service Authentication box.
Last thing: In the fusion table, go to File > About This Table. Copy the table Id. When you do operations with the table, you will need this id. You can store it in a variable if you want.
This property means that you can share and use multiple different tables with the same service account. Just share the other table(s) you will use with the service account and use that table's id when you do operations with that table.
Is there a good way to do secret key authentication for http queries from a salesforce app to my own web server? In other words, I'd like to give each company that installs our application their own secret key. Then each http call the app makes to our server (whether json or just a link to a hosted iframe) would look something like this:
groupid = groupid
param1 = value1
param2 = value2
signParam = signValue
Where signValue = md5("groupid=groupid,param1=value1,param2=value2,secretKey"
Then when I receive the query, I calculate the signature as well to make sure it matches before I perform any actions on our web server. The problem is, I don't see how I can assign and store the secret key for each company that installs our app (that is, have them store the secret key in their installation).
Is there a good way to do this that I'm missing? And if this isn't possible in salesforce, how else do you authenticate web queries before you perform actions in your own server?
Rather than trying to track it on the salesforce side, have the salesforce side send the users sessionId to your webservice, you can then use the API to validate that sessionId get details about the user, and check locally that the particular user/organization is licensed. There's some articles on the developerforce wiki about using this approach.