Is it possible to authenticate in Deezer by server side?
We are building a website with Deezer player and we don't want to for the end-user to login with Deezer Connect to listen the entire music.
Also, if its not possible authenticate by server side, is it possible to login by Javascript with one "master user" that emulates the end user authentication?
If you want to provide full-tracks access to your users, they absolutely have to be identified as Deezer Premium users. Therefore, you have to ask them to log in. In the JS SDK, the DZ.login method does all the work for you: http://developers.deezer.com/sdk/javascript/login.
That's a matter of rights management, Deezer can't provide full-track access to everyone, so the master user solution would not work either.
Related
I am trying to make Facebook Instant Game. We are interested whether or not we can use our own service for authorization instead of standard Facebook authorization.
Mainly, I have 2 questions:
Can user play if they are not logged into Facebook at all?
If they are logged in, can I use my own server to authorize the user inside the app?
Can user play if they are not logged into Facebook at all?
Unfortunately it is not possible to play Instant Games without a logged in Facebook account. This is because many of the APIs on the platform rely on an authenticated (e.g. ch
If they are logged in, can I use my own server to authorize the user inside the app?
You can authenticate the user on your own server using getSignedPlayerInfoAsync and sending an XMLHttpRequest/fetch payload. You cannot authenticate the user using cookies, however. These are blocked in the Instant Games container to preserve user privacy.
I'm running a Classic ASP website, that has its own user authentication and login mechanism. For example, In order to remember a logged-in user, ASP creates an encrypted cookie and a 20-minute session for each connected user. If the 20 minute session is elapsed, the server revives the session from the cookie saved previously, and saves some data regarding the user to the database.
I want to to be able to allow users to connect with their Facebook or Google identity, but the mechanism used by Facebook or Google is based mainly on Javascript and on client-side code.
How Facebook or Google login can be used while maintaining server side code in ASP? (So that the ASP server can still manage the session and save data regarding it, for example whenever a session is revived)
For me somehow it seems that it may become less secure to use client-side authentication as the code may be altered easily. Isn't this the case?
If I use client-side javascript and log in with Facebook, how would I update the user data retrieved from facebook back into my database, for example the user's first and last name?
For me it sounds that it should be a "server-to-server" communication (between my ASP server and Facebook's or Google's servers) and what they propose is a "client-to-server" communication ... Any ideas how this can be done?
Any help or explanation would be very much appreciated! Thanks.
I'll try to address your Facebook-related questions one by one. However, I will not give you an implementation or any ASP-specific feedback, but only a rough approach. Additionally, I recommend that you study Facebook's documentation on Facebook Login extensively to further your understanding of the matter.
1. Facebook documents the server-side OAuth 2.0 flow in their Manually Build a Login Flow guide. Basically you redirect the user to a specific FB URL that (in the parameters) tells FB to render the "Login with Facebook" dialog, and which permission scopes to ask for. Once the user approves the Facebook Login for your webapp, they will be redirected back to your web app, e.g. with an OAuth token in the query string, that your webserver can then exchange for a user access token.
Once you obtained a user access token, you could e.g. store it in your web app user's session.
2. I don't know what you mean. Client side apps are fairly secure. Perhaps you can convince yourself about how secure JS apps are when reading about things like CORS.
3. If you only use JavaScript (e.g. Facebook's JS SDK) and you want to store e.g. app-scoped user IDs on your server, you need to expose an endpoint on your server that your JS application can submit that kind of information to.
4. You state
what they propose is a "client-to-server" communication
Who are "they", and where are the proposing this? The resources I linked to in 1. should explain how you can use Facebook login in a pure server-to-server way.
I'm developing a mobile API and I would like to allow mobile users to log in to my mobile application using their Facebook account.
I've been struggling to find some detailed information regarding this request. Could someone point me in the right direction? I'm using the following Laravel package for OAuth2:
https://github.com/lucadegasperi/oauth2-server-laravel
As I understand, the user clicks the "Login with Facebook" button and then proceeds to authentication. Facebook provides the access token as a result. But how does a user account appear on our server? And to my knowledge, it is our server that should provide an access token which is tied to the user account on our database. Could someone clear this up?
Have you looked at the Facebook mobile sdk guides?
iOS: https://developers.facebook.com/docs/ios
Andriod: https://developers.facebook.com/docs/android/
The package you mention looks like it performs oAuth authentication, and I don't think you need that. If I understand correctly, you should be able to use the Facebook sdk to perform the authentication and tell your app that the user is authenticated. You will have to create a user account for them (for example, add a record to the users table in your database) and store their Facebook ID.
I'm writing an API for our product and I'm trying to understand how some basic OAuth works with regards to mobile apps that might leverage our (to be created) api.
Lets imagine that our website currently allows a person to LogIn to our site via Twitter OAuth.
On the callback from Twitter, our server retrieves the twitter OAuth result and if all good, then checks to see
if this user already exists in our DB (eg. lets assume the Email is the unique key). If they don't exist, we
create a new user.
Of course, we then log the user 'in', which means we create a cookie for them, for their browser.
So far - nothing new here. All normal stuff.
Now .. if we want to do this via an iPhone or Windows phone using their native language and the app's use our API, i'm not sure of the point where OAuth ends and our API takes over?
For example, lets pretend it's an iPhone app that takes advantage of our API.
The iPhone app will try to authenticate the user against their Twitter cred's. Ok, fine. But when it callsback, it's back in the phone, right? Not our servers. So then the app needs to try and create a new user? So then the iPhone might try and call /api/CreateAccount. But this means -anyone- can call this api? And how does the website really know they have authenticated? Only because the app says so? What's to stop the person from creating a malicious app and calling our API by flooding it with new account creations? And what about authentication to api resources? Forms Authentication isn't available here. So do people use querystring authentication over SSL for api calls? How does the iphone authenticate with -our- server?
I'm so confused.
Can anyone please explain the differences and common practices people are doing these days when they have a website and an api .. and use OAuth as the authentication mechanism, please?
The naive app would call not CreateAccount, but VerifyAccount with twitter's oauth set of data so you site and API could verify it. The site would respond with a unique userID and your iOS app would use that as it's internal user id. More info.
I'm creating a game for iOS (and maybe Android) in Flash (with Adobe AIR) and I'm trying to integrate Facebook. I've read lots of similar questions but I still can't get a clear answer. With my app:
Users will be able to login using Facebook at client side. (done this, using facebook-actionscript-api)
Users, however, should NOT be able to post anything server side, to avoid abuse (such as 'I made 9999999 points' posts).
I have a server (ASP.NET 4.0) and my server should be able to post on behalf of the player. (such as 'I made 1234 points', after a validity checking)
How can I validate my Facebook user at server side, restrict user from publishing using my App at client side, and let my server publish posts for that user?
Is there any option to grant the publish rights just to the server? Would Facebook's server whitelist work? But how would I then make API calls for user from client side (or should I move all the logic to server side after getting a token?
Thanks,
Can.
I say the best option is to assign a token for user and do the job server side.