I am using the soundcloud API in my custom player, which I also sell. So far I told each client to register a new app and add his own client ID. Is this necessary or can I also include my client ID in the code? I am asking that because of security problems, when other users have my client ID.
Regards,
Rafael
The client_id is usually public and could potentially by reused by somebody else, there is no way to prevent this.
Your case sounds like it's ok to include a general client_id in the custom players instead of one per site.
Related
I'm using Plaid Link and server-side API to let users register account/routing numbers with the auth product. We have customers with a bank that's retrievable in the UI's Select Your Bank search bar and with the API's /institutions/get endpoint, but it seems to not be a viable option to select and link. When I try to link it in the UI, there's a warning icon and a message that says "Plaid does not support connections between [Bank] and [Application]. Try another financial institution or check for another connection method."
Does this mean the bank can be supported, but my application isn't properly configured to support it? It seems to have the product I'm using (auth). I'd like to enable customers to add this specific bank, but also understand what the blockers are to supporting similar banks for my application.
I had seen that some banks require Oauth, but this one doesn't look like it does (oauth is false for it when I call /institutions/get). I wonder if there's some other requirement I'm missing.
You say you're initializing with auth, but are you initializing with only auth and nothing else? You can get this error if you're initializing with multiple products and it doesn't support all of them.
What's the bank? Knowing that would help a lot for troubleshooting; some banks are special snowflakes in various ways.
Try (Node API)
PlaidClient.institutionsGetById(institutionId);
which will give you the products the given institution supports.
Example:
{"country_codes":["US"],"institution_id":"ins_xxx","name":"XYZ","oauth":false,"products":["assets","balance","transactions","identity"],"routing_numbers":["xxx"]}
If you have generated a link token that does not contain the products listed from your bank (above), you will get the error "Plaid does not support connections between ..."
All I want to do, with PHP and google-api-php-client, is create a new playlist and add it to my YouTube Channel server to server. All guides seem to require me manually clicking a link generated to authorize a token. What?!? With an API key shouldn't I just be able to do server to server changes/uploads/edits without any need of human interaction?
I enabled the API, created API Keys and OAuth ID/Secrets, but still can't figure out how to do it.
Any guide would be appreciated. Server to Server, with PHP, without me needing to open the file in a browser to allow access to account.
Thanks
Tried this: https://developers.google.com/youtube/v3/code_samples/php for adding a playlist and can't get it to work, even after clicking the link and allowing access to account.
You want to start learning something called OAuth. Don't worry, it's only sounds scary. I'll try and ease it a bit for you. But before I begin, no amount of loitering around avoiding that OAuth thing is going to get you anywhere. Good news is: it's not that twisted.
Imagine you were YouTube. An application, say a web application someone wrote that you didn't know about were to come to you making an HTTP request on you.
The request were to say, "Hey, YouTube chum! Can you add this bunch of erotica to John's playlist and just make it all public for everyone to see?"
What would be your response?
If I were YouTube, mine would be --
"Yeah! fook you, dude! Go ask John first! Then, show me some proof that you did."
"And wait a second, before you leave, I forgot to ask, who the fook are you, in fact? You got something to show me for who you are?" I, the YouTube, would add.
You see the problem? For YouTube, there are really two parties involved in this transaction:
The application that's making the sleazy request; and
Poor John, who probably knows nothing of all this even when he should.
Otherwise, what's to stop any application asking YouTube (or Facebook or Google or Github or any place else) for John's data?
So, as far as YouTube is concerned, it needs a way for the application to authenticate itself with YouTube (thus the Application Id and Client Secret or App Secret you created on the Google Developer Console), and it needs John's permission to let the said application do what it is asking you (YouTube) to do (thus the need for John to interact with a UI).
Enter OAuth.
OAuth is a document of rules that allows this co-operative transaction. But for it to work, all the three, YouTube, the web application, and John, must first conspire together.
There are three parties in OAuth:
The OAuth server -- that has John's data. In this example, it was YouTube.
The third-party application that wants to do something with John's data that's kept on the OAuth server, i.e. YouTube.
Poor John, a user on the OAuth server (YouTube), and also wanting to use the third-party Web application that wants YouTube to do something with John's data.
Now, there's a whole lot to learn about OAuth before you write a single line of code, and I can't write it all here but here's a YouTube playlist that starts by explaining the very basics of OAuth and then provides demos in (sorry, no PHP) C# and also in JavaScript.
Once you understand the OAuth transaction mechanism and see some code, then re-visit the YouTube API documentation page you linked to and it'll start to make an enormous amount of sense. It'll click and you won't need to look any place for help writing that example. It'll just come out of you like poop. :-)
While developing an iOS and Android app for a backend API, I'm using separate client IDs for each. However, I noticed something that I find odd, and I'm hoping someone can explain why this works and if it's ok to work this way.
What I noticed is that if my backend API code supplies the Google Sign In client object with a client ID during instantiation, then it must match the client ID used by iOS or Android. (The client ID is called "audience" in the Google API code.) However, if my backend API code do NOT supply the Google Sign In client object with a client ID, then iOS/Android will always validate.
This is how it works whether you use php, java, nodejs, etc.
I expected not using a client ID to fail, same as using a mismatched client ID.
So, my questions: Is it valid to have the backend server validate ID tokens without specifying a client ID? Is there anything wrong or unsafe with doing it this way? What's the point of having the second part of the if statement that checks to make sure that client.audience (if set) match idtoken.audience, if you can just leave client.audience blank and it works anyway?
I wonder about this because related documentation, such as the Android docs, state this as part of the verification process when authenticating with a backend:
The value of aud in the ID token is equal to one of your app's client IDs. This check is necessary to prevent ID tokens issued to a malicious app being used to access data about the same user on your app's backend server.
If the point is to prevent malicious apps from doing bad things, why is valid to simply not use a client ID during verification?
Thanks in advance! I'm hoping someone can help me understand this. I haven't found a solid answer in Google's documentation.
Currently, I have been tasked to utilize the Google People API to ask for a user's basic Google information along with their public phone numbers. So far the results have been positive.
The solution my team and I have incorporated the Google People API integration in has the capacity to be utilized across thousands of domains. As a result, my question is simply, How can my team members and I ensure that any our clients that utilize our solution with their own particular domain get our new functionality built with the Google People API?
Keep in mind, our clients have the flexibility to have http/https and any subdomain on their site. Entering each domain possibility for our client base one by one would not be an easy task. I'm seriously hoping there is a solution around the single, explicit origin entries.
Thank you for your time and help.
Warning:
You must remember that if this is source code you are giving your clients that you are not allowed to release your client id and client secret. This includes plugins and scripts.
On November 5th 2014 Google made some changes to the APIs terms of Service.
Asking developers to make reasonable efforts to keep their private
keys private and not embed them in open source projects.
So if your clients could view the code of your application and see your client id and secret you should not be giving it to them.
Read more about this issue Can I really not ship open source with Client ID?
Recommendation:
The best solution for you will be to instruct your users now to create there own project on Google Developer Console and create their own JS origins.
You may just have to provide your own wrapper around the target API where you authorize the client request yourself and then do the request from Google using your own credentials.
I would like to discuss my situation and understanding.
We need callers to video call customers. For this, I've been using Tokbox video chat.
I have setup a server for authentication purpose. It creates singleton session and generate tokens as given in the example code.
This is what I have in my mind till now
If callers A and B want to call customers C1 and C2, I guess I need to create two different sessions and their separate tokens.
I need to store session id and tokens for A and B separately in database or session
I need to send the session id and token to client mobile app so that client can subscribe
I don't need code, but just want to know if I'm going in right direction.
If a similar type of example links are available, that would be great
Thanks
Yes, I believe you're correct.
You can think of sessions like rooms, anyone whom joins the session (or room) can see and talk to each other.
Tokens can be thought of as keys to the room. If you have a token to the session, or a key to the room, then you're able to gain access.
You'll need to generate these sessionIds and tokens on a server, and store them in some sort of database. When caller A calls customer C1 a new sessionId will be generated. Then you'll need to generate a token for A and C1. They can now talk to each other. It's up to you to ensure that only A and C1 have access to the sessionId and tokens (using some sort of authentication and authorisation system).
I know the answer is too late but may help someone. I think you need not to store anything in database, so in your case, you are calling from web to mobile. I have implemented the same for my project. So the approach I am following is that I am creating an opentok Session and sending it to Mobile app using FCM, and connect on both web and Mobile. Once connection is established, We can start the actual Video chat. Since we are using FCM, we have mobile device Id, so we are sure that we are sending it to User it is intended for ( thus doing authentication as well)