I am currently building an analytics dashboard that consumes client data from various API's (Google Analytics, Mailchimp etc).
Now I'm at the point of hooking it up to the Facebook Graph API (v3.x) and I am currently able to pull in a pages fan_count utilising a Long Lived token whilst the App is in development mode.
My question is - this app isnt going to be publicly accessible and only provides my Laravel installation with this fan_count metric so do I need to worry about putting it into Live mode and submitting it for review? As far as I understand, I can dynamically request the access to token to be refreshed anyway so in theory I dont see any reason for me to ever need to make the app 'live'.
Just looking for confirmation that my understanding is correct.
Thanks
Jay
Related
I've developed a website with the usual crud functionalities in Codeigniter and MySQL. I'm now tasked with creating a mobile app (with the same functionalities ) in Ionic 2.
To access my database with Ionic, I created a REST api -- which I was able to manipulate smoothly.
My questions are:
How, or can I, use my MySQL users' credentials to log in on my Ionic 2 app?
How can my web and mobile can share the same database?
I've been reading a lot about Fire base,etc. However, my tiny brain is unable to comprehend whatever I read. If anyone can point me to right direction, I would highly appreciate it. Thanks!
When developing an Ionic App you have to think of it as if you were developing a regular website. The only difference is that you have access to native device features with cordova plugins, but the whole flow is almost exactly like in a regular website (it is an angular application after all).
This means you can use your API just like you use it in your website. There is no need to use firebase. (Firebase is kind of like a database itself that you could use INSTEAD of your MySQL backend)
Totally agree with #Andreas. When you build a modern application that supports on the different platforms such as web or mobile, you need to design a standard API and then next step is to build a web application/mobile app to consume this API. And because of all the web/devices are all consuming from the same API, they are interacted with the same database. Unless they are using different API.
Can refer to the image below for easy understanding.
So talk about how authentication and authorization can be done from the mobile app or from the web app. You should take a look at OAuth2. It is a protocol for securing API services from untrusted devices, and it provides a nice way to authenticate mobile users via what is called token authentication.
The workflow will look like below, on both web and mobile app.
A user opens up your mobile app and is prompted for their username or email and password.
You send a POST request from your mobile app to your API service with the user’s username or email and password data included (OVER SSL for sure. If you don't know about it, google it).
You validate the user credentials, and create an access token for the user that expires after a certain amount of time.
You store this access token on the mobile device, treating it like an API key which lets you access your API service.
Once the access token expires and no longer works, you re-prompt the user for their username or email and password.
Reference
REST API from PHP
The ultimate guide for Mobile Security
I'm working on a project where I'm developing a platform. As a solo-developer I made the decision to use Lumen as a PHP back-end and create an RESTful API.
Web shops should be able to install a plugin so they can access the API without having to code themselves.
I need to keep track of the web shops that use the API. I just need the same way to retrieve access tokens like Twitter and Facebook do when you register an app.
So I was thinking about OAuth2 Server but I have never used it before so I'm not sure if I'm on the right path...
If you want your own OAuth2 system then yes you will need a server running it.
The idea of OAuth2 is to authenticate your clients where a shop equals one client.
OAuth2 is not about individual users but clients. With that idea in mind you can setup an OAuth2 server and its only job would be to authenticate each request, make sure it belongs to a recognized client and then issue a token.
With that token you can then go on and issue more requests to actually interact with the system you are building. This is a very high level view of the entire system, of course.
There can be multiple variations on this, how tokens are issued, what type they
are etc. I prefer JWT ( JSON Web Tokens ) as it's JSON and thus lightweight.
A quick search revealed this: http://bshaffer.github.io/oauth2-server-php-docs/overview/jwt-access-tokens/
I do have my own article on building your own OAuth2 system, however it is based on dot net not PHP. You are welcome to use it though maybe it will help clarify the concept.
Here's the link : https://eidand.com/2015/03/28/authorization-system-with-owin-web-api-json-web-tokens/
My question is not deeply technical but more of a system architectural one.
I'm designing an API backend in Go Lang. I'd like to have several clients, like a web server, cell phones etc.. I imagine that all these clients should have a secret API key so to validate that they can use the API. At the same time the web frontend is going to have a lot of users with different restrictions. I'd like for these users to be able to log in with their facebook or Google account. That should require OAuth authentication as I understand. My question is now where should I add the OAuth. Only in the frontend and then save the user in session or also between the frontend and the backend. I'm highly confused about how I should set up this communication and authentication.
I'm building the web server in PHP and I'd like the web frontend to be really light weight and more or less only function as en empty shell/view for the Go API. I've build systems in plain PHP/MySQL before but I'd like to make a shift to Go based APIs.
How would a URI look like to the API from the web server frontend for let's say a show profile page? I imagine something like a GET call to "http.//backend.com:3000/[api-key]/[api-secret][oauth-token?]/profile. Then some middleware to authenticate the web client and another piece of middleware to authenticate the user. Would that be "the right" approach?
I hope you guys can point me in the right direction.
Thanks in advance.
If you look at your facebook or google developer docs, you will find examples on how to integrate with their oauth login systems.
OAuth, or at least the last step of it, really must be done on the back end as you have to assume your front end is a bad guy hitting your system.
For go oauth, take a look at: https://github.com/golang/oauth2
You will likely have a http.HandlerFunc("/oauth/google",yourGoogleFunc)
and http.HandlerFunc("/oauth/facebook",yourFBFunc)
type thing, then you register that URL on your dev account with those companies.
while testing, it's easiest to use localhost:8080 (or whatever) as the callback url so it works on any machine as long as you are using a local browser.
For my web application - I need to fetch all the data for a particular facebook page. What kind of permissions do I need. Do I really need to create a canvas app for it?
I dont intend to do anything on FB - but use some of the data available to arrive at some conclusions in my web based application which will be hosted on a server outside of FB.
Facebook's API documents should provide everything you need:
https://developers.facebook.com/docs/graph-api/reference/v2.1/page
According to the permissions section, you'll need either an App token or a User token. Since you're talking server-to-server (I'm assuming this is server-to-server on account of the PHP tag), you're going to want to use an App token:
https://developers.facebook.com/docs/facebook-login/access-tokens#apptokens
You should be able to create a Facebook App from within your Facebook account, which will provide you with an App ID and App Secret. You can use those to make calls directly to the API.
I've seen this question earlier on your website, but it didn't quite help me out yet...
Here is what I'm trying to achieve:
I have a Content Management System (PHP) that is installed on the server of the various websites of my customers. Whenever a user posts a new message on his website, a shorter version of this message is sent to social media sites. Right now, this is possible with twitter (using the OAuth library). But I would want it to work with facebook too....
When I create an app in Facebook i HAVE to assign ONE return URL. But because the to-be-used CMS system can be anywhere, it's quite useless to me?
Or is there a way to make this work?
Best regars, Robert
I'm not sure your exact need for the return URL here. However, having the CMS communicate with Facebook from the server side would be performed with the Graph API with the OpenGraph protocol. This sounds like what you are doing with Twitter's OAuth.
You can then code your CMS to use your API credentials and never leave the CMS server. There is even a PHP SDK available for Facebook which sounds like it would integrate well for you.
If the CMS is at a different URL for each individual, then they each need to create an app on their Facebook profile to add the communication in this method. Because Facebook requires the basename of the URL to be the same by design, for security. This is typically performed by enabling the end-user to configure their own "app" in their profile for communication and is very commonly done with Wordpress applications for the same purpose.