I am looking to display the current song I am listening to on Spotify. There is an endpoint to obtain this here (Spotify Web API Player) which requires authentication through the Spotify web API.
If I have obtained a Client ID and Client Secret from my app settings, which authentication type is suited to my needs?
I've looked here (Spotify Authorization Flows) but from my understanding and confusion, I believe this cannot be done as the request for authentication would be to authenticate the user against my app and display their current song and not mine.
Fundamentally, I'm looking for a way to display my current song without the end user having to request access to my app but instead, the app uses my details.
Thanks in advance.
Arielle from Spotify here.
The Authorization Code Flow is what you're looking for, but you are correct that in a standard implementation users would see their own data (which makes sense - you usually don't want users seeing other users' data)
However, you can set it up such that you're the only one who authenticates and only your data is shown. I actually made an app to show my currently playing track a little while back. Check it out on Glitch here: https://glitch.com/edit/#!/ari-currently-playing
You can simply start editing the project to "remix" it and make your own version!
Hope this helps, let me know if you run into any issues!
Related
I want to develop real time chat with channels and these are my needs:
PHP backend to manage site
Redis as session and data primary storage
Pub/Sub to send messages only to channel's interested users
one WebSocket connection with which the messages will be send and received.
(optional) NodeJS to use great npm packages like timesync or socket.io
I see two different architectures to achieve this:
with Socket.io
with Crossbar.io
These are my questions:
Which architecture I should choose and why?
The key is the user id cannot be obtained from client, because it can be malformed. So in the first architecture I think on every socket message I should attach PHPSESSID value from cookie and on sever-side retrieve PHP session from Redis. Am I right or there is better way to get user id?
I wonder if getting user id in second architecture can be done differently?
Edit:
I choosed Crossbar.io, cause it is very powerful and allows to communicate many different language applications in real time. After studying examples, I come up with this:
On every login user have generated secret key in database.
PHP client (Thruway) connect to Crossbar server and register custom WAMP-CRA authenticator
User's browser connect to Crossbar server and is challenged. Secret and auth_id (user id) are loaded from DB with page load, so it
can accomplish challenge and send response.
PHP authenticator search in DB for user with provided secret and id equal to auth_id. If there is, then it successfully authenticate
session. Now we can trust that auth_id is real user id.
These are my question:
How I can get auth_id on subscribe?
I also added cookie authentication and browser is remembered after authentication. But when I look in Chrome DevTools there is any cookie nor value in local storage. Even after clearing cache my browser is still remember by Crossbar. I wonder how it is possible?
Edit2:
Maybe I was misunderstood, but the main question was choosing appropriate architecture and getting trusted user id. There was no attention so I awarded bounty and after that I was downvoted. I read a lot about real-time apps and finally decided to use Crossbar.io, so I edited question to be related to it. Then people started upvoting, proposing another architectures, but not really answering my questions. After all I managed to do it myself and presented my answer.
About getting user id:
Every real-time chat examples which I saw, was getting id from client. It is unsafe, because client easily can manipulate it, so I needed to find another method. After reading WAMP specs I finally figured out that I have to authenticate user not only in app, but also in Crossbar.io. I choosed the dynamic WAMP-CRA method and implemented as following:
PHP app connect to Crossbar server and register custom authenticator (similar to example)
After user login in app there is generated secret key for him and saved in database. After logout, key is destroyed.
Workflow:
Every loaded page contain user id and secret key loaded from db:
<script>
auth_id = '<?php echo $user->id ?>';
secret_key = '<?php echo $user->secret_key ?>';
</script>
User browser connect to Crossbar.io server and get response with challenge from custom authenticator.
It calculate signature using key and send along with auth_id to Crossbar.io server
Authenticator gets from DB secret for provided auth_id and calculate signature. Then signatures are compared and if they are equal then authentication is successfull.
Now auth_id contain user id and we can trust its value. Now you can refer section 'How I can get auth_id on subscribe?'.
Answers:
How I can get auth_id on subscribe?
By default publishers and subscribers does not have any knowledge about each other, but documentation show there is option to change it by configuring disclosure of caller identity. Then you can get auth_id from callback details:
PHP:
$onEvent = function ($args, $argsKw, $details, $publicationId) use ($session) {
$auth_id = $details->publisher_authid;
...
}
$session->register('com.example.event', $onEvent);
JS:
function on_event(args, kwargs, details) {
auth_id = details['publisher_authid'];
...
}
session.subscribe('com.example.event', on_event);
I also added cookie authentication and browser is remembered after authentication. But when I look in Chrome DevTools there is any cookie nor value in local storage. Even after clearing cache my browser is still remember by Crossbar. I wonder how it is possible?
First of all, clearing cache and hard reload does not remove cookies. When I was asking this question there was any cookie presented, but today I can see cbtid:
There was Chrome update two days ago, so maybe this was caused by bug in previous version.
I deeply light Streamer which is used by NASA to forward truck loads of data per second.The most reliable server for real-time messaging.
Power web, mobile, tablet, desktop, and IoT apps.
Optimized data streaming for web and mobile.
Lightstreamer enables several forms of real-time messaging. It is flexible enough to be used in any scenario, including mission critical applications.
► Real-time Data Push and Web Sockets
► In-App Messaging and Push Notifications
► Pub-sub with fan-out broadcasting and one-to-one messaging
► Firewall and proxy friendly
► Adaptive bandwidth throttling
As for your first question to get the auth_id on subscription , just monitor connection subscriptions then store tier upon successful connection.
Also cookies are not recommended , use jwt.JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.Authentication is one of the big parts of every application. Security is always something that is changing and evolving.JWT helps you solve that concern.Since it is stateless.
PHP Ratchet is one of the best implementations I've used for real-time communications via WebSockets. Its based on ZMQ Sockets which is used in several online gaming applications and chat applications.
The following examples will get you started pretty quick and will answer your questions around auth_id and subscriptions:
http://socketo.me/docs/hello-world
http://socketo.me/docs/push
Overview of the Architecture:
http://socketo.me/docs/push#networkarchitecture
I would advice creating individual connections(toppics) per conversation as it doesn't really take a hit on performance and will add an additional layer of security per chat.
I have a client that wants to take orders via an online form, with the idea being that an order can be submitted and stored in a database via my application while simultaneously generating an invoice on submission in QuickBooks.
How do I do this in PHP when the person entering in the order is not the client but a client of the client? It seems like Quickbooks uses Oauth tokens and a javascript library to generate them to connect a company to an app, but I'm simply writing a backend for one company and want that backend to create invoices when saving an order. How do I think about this?
I'm not interested in anyone having to hit a button that says "connect to quickbooks" especially not the person filling the order because again, that person is a customer and doesn't need to know about the internals of the customer's invoicing system.
I just really want to use the Accounting API to generate invoices. Is there no way to simply link my backend to my one company directly in the Quickbooks SDK configuration and achieve this, or do they need to use a javascript library to get tokens. I'm unclear about what direction I should be going in and don't want to waste time with a client-side library if I don't need it to do backend logic.
Here's some example code that does exactly what you're looking for:
https://github.com/consolibyte/quickbooks-php
Along with a quick-start guide:
http://www.consolibyte.com/docs/index.php/PHP_DevKit_for_QuickBooks_-_Intuit_Partner_Platform_Quick-Start
Also see notes about your comments below -- you're on the right track, you're just misunderstanding how OAuth works:
It seems like Quickbooks uses Oauth tokens and a javascript library to generate them to connect a company to an app, but I'm simply writing a backend for one company and want that backend to create invoices when saving an order.
Correct, Intuit uses OAuth, and a little Javascript thing to kick off the OAuth process.
I'm not interested in anyone having to hit a button that says "connect to quickbooks"
Someone needs to hit this button... BUT only ONE PERSON needs to hit the button ONCE, EVER, and then NEVER again.
The owner of the company (e.g. your boss) needs to click the button ONCE, which gives the OAuth creds (and the realm ID) to you. Once your boss has done this ONCE, then you have the creds to use forever, for all of the actual customers.
Your customers (e.g. the people actually checking out/placing orders) DO NOT click any buttons, nor do they see or have any idea at all that you're even using QuickBooks.
just really want to use the Accounting API to generate invoices.
Cool, you can totally do that!
Is there no way to simply link my backend to my one company directly in > the Quickbooks SDK configuration and achieve this, or do they need to use a javascript library to get tokens.
Follow the quick-start above. It should take you about 15 minutes to get a working OAuth connection, and then you never need to use the client-side stuff ever again.
You only need to authenticate every 180 days btw.
If you use the reconnect script, you only need to authenticate ONCE, and can automatically renew the tokens every 180 days, no user-interaction required.
https://github.com/consolibyte/quickbooks-php/blob/master/docs/partner_platform/example_app_ipp_v3/reconnect.php
Well with the realm_id for example, I don't understand how that relates to ouath.
The realm ID is just a unique identifier for the particular QuickBooks Online company you're trying to connect to. Yes, you need to store it. If you use our libs, this is done for you automatically.
I guess I don't understand if I'm developing for one client why can't I just get their realm_id from them and then keep using it rather than making them do some form of authentication?
Again, they only have to authenticate ONCE. That's Intuit's way of giving you the realm ID and credentials you need to connect. Once you've done it ONCE, you never need to do it again. It takes all of about 30 seconds.
If they were to just give you OAuth creds without any authentication, it would be a gigantic security hole. If you read the Wikipedia article on OAuth it talks in depth about this, and the goals of OAuth.
Okay I think I get it, so they have to authenticate once every 180 days?
Once every 180 days, UNLESS you use a reconnect script, in which case they just authenticate once and then never ever have to worry about it again.
So I can store the token and the realm_id in a database before it expires and just use that?
Yes.
In this way my client can authenticate and then my scripts can generate invoices for them when their customers visit our website?
Yes!
I am trying to get a list of all Google Apps users of a domain onto a public PHP website (without visitors of the site needing to login or do anything). I have a basic understanding of what needs to happen but can't quite piece it all together. It can't be as hard as it seems to me... could it?
Authentication and Authorization:
I'm pretty sure it needs to use OAuth 2.0 ... but am unsure whether it needs 2 legged or 3 legged. I got another section of the site working with ClientLogin but that won't pull in Google Apps profiles, only user's first and last names (I need the other profile fields). I have set up the API access within the account and have that side of things all set (I believe).
I have found this page, which shows how to construct a URL request to get all Profiles (in every language except PHP of course) but don't understand how to implement this.
http://code.google.com/googleapps/domain/profiles/developers_guide.html
I also tried this example but it just gives me a 401 after I enter the credentials. http://gdatatips.blogspot.com/2008/11/2-legged-oauth-in-php.html
I don't know which frameworks or includes are needed to accomplish this either. I have tried zend, OAuth.php and a whole bunch of other bootstraps... but keep getting lost as to what each is doing.
If someone could help me by outlining:
Which files/framework I need to upload and include as a bootstrap
What variables within those files I need to update with the Google credentials
How I integrate the Google Profiles "Retrieve all Profiles" request with PHP
An ELI5 (explain it like i'm 5) overview would be very much appreciated... I'm sorry for my apparent incompetence, but I have been reading articles for nearly a week and have not gotten anywhere.
Thank you in advance for any help provided.
Good question.
You'll need to implement the Google OAuth 2.0 process as it's described here (experimental?), because someone (you) will need to give your app the initial permissions to access Google Apps API. Steps are:
Register your domain with google (don't remember the link)
Redirect/send browser to an authentication url: https://accounts.google.com/o/oauth2/auth, with the appropriate request params (see the first link). You'll need access_type=offline, your scope would be https://apps-apis.google.com/a/feeds/user/
Get a code back, then exchange for a refresh_token, an access_token, and a value specifying when the access_token will expire. Store these in a database
Whenever you need to make an API call, check if your access_token has expired or not, and refresh when necessary, which is what the refresh_token is for. The refresh_token is valid as long as you don't revoke the access you gave to the app.
OAuth Playground helps a lot. Good luck.
Hello I am looking to build a basic API and application/apps system on my social network something like Facebook or other sites have, my site is in php/mysql. Here are some questions.
1)
Basically what I want to do is give a user a API key and secret. After I have these how can I use them in my php app to authenticate a user request which would come from there server?
2)
I can basically build an API to send a request to my server with CURL and get the result back to the page in XML or JSON or whatever, the problem is when sending the request the user would have to know the user ID they want to send to lookup data against, this is fine for an API but I am wanting to have an Apps section where the user's app site would be using the API and would be loaded into my site in the app section with an iframe, the problem is, I need to find a good way to make it where a logged in user on my site can go to the app section and go to an app and there username should be available to that page loaded in the iframe. Facebook and myspace do this somehow and many other sites; I am lost how to get around this hurdle.
Any help on any of this is really appreciated, thank you
Update:
I just had an idea, if I require a cookie to be set when a user visit's my site, then they would have a cookie and it could hold there User ID, then my API script could look for that cookie to exist and grab it's value?
If you plane on using an IFRAME, then no, your API hosted on a separate website (the website inside the IFRAME) would not be able to grab the cookie. The cookie is only visible on the website that it was set for.
I have only used Facebook API with the FBML (not the IFRAME,) but all they do their is basically replace what's in the page with the info that the "tag" is calling. I'm not sure if there is a better way, but you could possibly call a page on the app's server (say the app is hosted at http://example.com/app/, and you called http://example.com/app/?id=28318&name=John%20Maguire,) and have your API code handle it and turn it into a variable?
Maybe you should look into the source code of the Facebook API client.
user signs up for a key and secret from my site, then they can send/receive from my REST server.
Where I need help is when a user interacts with the REST, how can I determine if they are authenticated using THEIR key and secret? Basicly this will be for a social network site app area. I have seen that many social networks have an app area and use REST and OAuth and sometimes OpenSocial but I have looked at those and they are a bit complex for my needs I think. As for authenticating with OAuth, I guess I do not really understand exactly how it works, maybe it is what I am looking for though? I don't need to authenticate the user who views the page that is running the API, I need the owner of the app's server to authenticate to send back and forth with my REST?
Any advice on how to do this the best way? I would like to do it the best method for future growth, so if I could do it like the big boys do (Facebook, myspcae, hi5, bebo) that would be the way to go I think.
when a request is sent it should pass the key in the URL to my server but they should have there Secret somewhere in there script, I am not clear how to make that work with each other?
OAuth is almost certainly the best way to go here. Using OAuth, you can provide authorization to almost any kind of web-based API that you would like (REST is fine, but so is plain ol' XML over HTTP).
There are some Stackoverflow articles on how to get started with OAuth.
I also find Google's implementation worth studying, as it's both well documented, and a very good implementation from which to take inspiration. They also have a very helpful "OAuth Playground" that will walk you through an OAuth request step by step.