I'm working out a project that is tightly connected with Facebook. However, I got several questions related to the program flow.
A user may authenticate through Facebook, allowing me to use the user's access_token for data querying. Now, when I need the data, I call the api. This happens more frequently (on different pages, with the fields required to provide the view the needed data). A disadvantage I see is that I query Facebook's API everytime a request is made on one of my website it's pages. Is this a bad thing to do?
Another option would be to store the entire data array in a session (or request it when no session is found) and pull the needed data out of it, and not just the fb id and access token.
If someone has a better idea, or has experience with this, throw it towards me. Any tips are appreciated.
Regards,
matvp.
I guess It's better if you
Query all the data that you may need and Store it in the Session, and use the session further on with your website.
or, Query all the data you want and store it with ID in your DB whatever your DB is, and then also Query your DB whenever you need the data
Sure it is better that you store user data you may need for the entire session, a simple caching of these data let you avoid a lot of queries.
The following Stack Overflow question could help you:
Can you store facebook users' data and for how long?
Related
I'm not sure where is the best place to ask this question, so maybe if this is the wrong place, someone can help move this question to a better group?
It has elements of programming, user experience and database, but doesn't really fit well into any one category!
I need to take data and display it in a graph on my site. This data is available from an API.
But I cant decide if it is best to just get this data from the API "live" when needed, or to save data from the API to a local (on my own server) database.
Both methods have pros and cons.
Getting the data live means more URL requests, more latency, and if the site is used by many users, may limit the API access. I 'assume' the site will always be available if using the data live. The API data is also restricted to the past 2000 historical data points.
If I use a cron job to request the data, say once an hour, and save it to my own database, then I am only calling the API once every hour. Accessing my own database should be faster than calling an API from a URL GET request when drawing my page. And if my site is up, then my database will be up, so I don't need to worry about the API site uptime. And I can store as many historical data points as I want to, if I am storing the data myself.
But it seems wasteful to simply duplicate data that is already existing elsewhere.
There could be millions of data points. Is it really sensible to store perhaps 50 millions pieces of data on my own server, when it already exists on an API?
From the user's perspective, there shouldn't be any difference as to which method I choose - other than perhaps if my site is up and the API site is down, in which case there would be missing data on my site.
I am torn between these two options and don't know how best to proceed with this.
I think it is inefficient to do a request on each page visit to collect the information. I would like to know what the theory of best practises are regarding to working with data that is received from an API.
Should the data be stored in my own database or should I just make a call to the API every time?
As example if I would use Strava to get my running results. Should I just use the result directly from the API or should I store these in a database. And than check after a certain period if there are new or updated results and update my database accordingly?
I have read some articles about RESTful API's but they only give information about how to get, delete, update the data etc.
It depends on what you are using it for...
If the information is likely not to change and is likely to be reaccessed on your site then store it.
Otherwise just get it from the API, it will always be up to date and it's less code to write if you don't have to store it.
If you are storing it and you know what information you are likely to require you could retrieve in the background at set-intervals.
You can also look at other factors when making your judgement, such as the speed of the API or if you have a API call limit.
You are probably not finding an definitive answer as there isn't one, but I hope this clarifies this for you =]
I don't know of Strava or whatever API you will use.
In my case, generally in applications there is a need to keep track of what have been exchanged with an external system, for example to give proof that the data has been read or written.
For this, usually there is something kept in the local database, and usually it does not have to be the track of the complete data exchange.
I've built a MVC 'framework' for learning purposes, and I'm struggling with this problem:
I am working on a CRUD application and I don't know how I should delete the records from my database. Right now I'am doing it through URL.
example.com/controller/delete/id that is how I delete a record from the database. I don't really like this way, because anyone could unintentionally or intentionally delete database records.
So my question is: How should I implement this feature?
You've got a number of issues here:
First of all, you need to know who is performing the operation, then you need to decide if they're allowed to do it.
For the first, you need a login system which issues a session id to the client (usually via cookie). You then use the session id on the server to look up who the user is and check if they're allowed to do the delete. This is usually handled through granting roles to users and then allowing roles to perform certain actions
Incidentally, GET requests are used for requests that do not modify the server state and can be repeated with no side-effects. POST, (or PUT/DELETE) should be used for any action that makes changes. Browsers will not send a POST twice without prompting the user explicitly.
You need to send data with POST data.
you can also use GET with CSRF token
I think both way is good.
You need to include a security layer to your MVC in order to define who can access specific resources of your API.
The most simple way is to require a key parameter in the URL that needs to match a key that you would have predefined on the server side, but be aware that despite it will prevent random user to update your data, it might not be suitable depending on the security level you want to achieve for your application.
I am looking to be able to have my Cordova/PhoneGap 3.0 app, connect to a database and retrieve user information given a particular username to query data for. Then I also want to store the returned information on the device for future access.
I imagine that I would need to pass the uername and password entered in the app, to an AJAX post method, that links to a php script that takes the input and queries the database, then returns the information I need... But im not sure as to how I will go about doing that because I've never used AJAX post methods to a php script to return information.
As for storing it, I have heard that there is somewhat of a SQL database present on the phonegap cordova framework? I may be wrong on that one, maybe it was a hack I saw at some point, but I am just looking to see how I could go about storing and calling upon stored variables in the applicaion.
Any suggestions or help would be greatly appreciated!
Thank you in advance!
I haven't done this with PhoneGap, but I've done some work on something similarish using another cross-platform mobile framework, so I thought I'd add some comments --
First, I don't think storing the returned data on the device is necessarily a good idea, because if the data can be edited, how will you make sure it will stay in sync with the server? Easier just to re-obtain it when you need it.
Secondly, when I did this, I ended up writing an actual login API in the PHP script that would return sessionID, which would get stored on the phone, then I could send sessionID back when the logged in session was required to avoid saving passwords (and what if password changes after they enter password?) or repeatedly asking for passwords.
Thirdly, I'm not sure how PhoneGap works, but I had difficulty getting it all to work together due to cross-domain request problems (especially with post.) You'll probably at least have to part of what I did, which is add headers to your php scripts:
header('Access-Control-Allow-Origin: *');
header('Access-Control-Allow-Headers: X-Requested-With');
Forth, I recommend looking into Restful. You'll probably at the least want your PHP to return the results in json.
I'm currently developing an app for iOS-devices. This app downloads data from a wordpress blog, but fetches a nonce-token first. This has been tested, and is showing to take about 2~3 seconds, which is a lot, considering it's a mobile device that should have the data ready in a few seconds. In addition to this, the data has to be downloaded as well, which takes another 4~5 seconds.
In the data-fetching-method there are several security-measures taken, for example a secret string that needs to match on both the web-server and device (of course encrypted), and some sort of simple UDID-validation + some header and useragent-tests. Is this enough, or do I really need the nonces? It's not like there is any sensitive data being passed through, and if it was, I'd of course encrypt it further.
Is it really necessary for me to use nonces?
Thank you.
If you are downloading public data, there's no need for the nonce authentication stuff.
If you are going to be modifying data on the server, or fetching data that is not public or otherwise has some kind of access control around it, then you'll need whatever mechanism Wordpress requires to gain access (which it sounds like is a nonce-based token approach).
If it's taking a few seconds to get that token, how about fetching it on app startup/resume in the background?