BUMP: This is not a dead request. I'm still hoping to get a solid answer from someone at Facebook or anyone else. Thanks.
Revised Inquiry: I don't know if I'm not asking the right question, or if I'm asking a valid question that no one can answer.
New Questions:
Can we use FQL or another means to get all of the requests seen at reqs.php? I'm essentially looking for something like this:
SELECT request_id, app_id FROM apprequest WHERE recipient_uid = me()
Notifications return that data but app requests are often batched into a single record with a link identifying some but not all requests. I want individual records for all app requests currently open. The data to do this must be available, as this is the data used to build notifications! It just seems that this is not being made available to us. :(
Thanks!
Original Inquiry Follows:
I have an app that aggregates various sources of Facebook information for a user. One of the sets of data I'm working on is the collection of apprequests which have been sent to this user by friends. For example, I open GreatApp and click to send a request to you. You may or may not use GreatApp but let's assume you haven't blocked requests from it. You now open my AggregatorApp that shows my request to you, and the included link back to GreatApp. The data you see is the same as at reqs.php but formatted differently, with much more data, and of course simply much better. ;)
I thought that is what we got in apprequests. From this question I'm understanding that apprequests is a collection of requests sent out by the current application.
When using path/me/apprequests, we don't need to specify an app ID. But I believe here we do need to provide an app token rather than a user token. Is that correct? If that's correct then this confirms that the requests are those that this app sent out, not requests generated by other apps.
When using FQL, we need to identify the uid of the app as well as the id of the request in order to query the apprequests table. I get that, but even with a valid request id and app id (and valid permissions) FQL doesn't return request data. (I haven't checked with an app id, maybe that's the key.)
I am hoping people will provide some concrete examples for any of the above, specifically getting inbound requests from other apps, and confirmation about what token or other detail is expected for /apprequests and the apprequests table to return data.
Thanks!
Other threads asking the same question without a good (or any) response:
thread1 thread2
You need to make a graph api request to get the apprequests connection for a user. See the current documentation here: http://developers.facebook.com/docs/reference/api/user/.
In the Connections table, the documentation correctly notes that you need an application access token to retrive the requests to that user. There's a bug in the documentation under (http://developers.facebook.com/docs/reference/api/user/#apprequests) that claims you need a user access token. This is incorrect, and (as you've seen) will return an empty list of requests.
Requests sent by an application are only visible to the application. The user can't see or delete these requests (though they are able to hide the request). The reason for this is that the applications can put data into the requests (255 characters) that's never exposed to the user or other applications.
I don't think there's a way you'll be able to aggregate a user's requests from apps that you don't have an access token for.
What I have found out (before my question was deleted) was that you can't access requests with a user token, and app tokens can only access requests that app has sent (and I found that out myself in the documentation and playing with the graph explorer). Since I know there are iPhone apps and browser plugins for processing requests, I assume they are accessing the page itself and parsing the data (like scraping a site). The downfall to that approach is that on the request page only around 100 requests from each app are shown at one time.
(Unless some people have found a way that they aren't sharing...)
You are right, you need the app_access_token and not the user_access_token.
I think the FB documentation has an error.
The definitive answer was provided by a Facebook developer here in response to my bug report. The resolution is that this is By Design. This relates to the note by #noah-callaway that there's probably some app-specific data in requests that should not be available to other apps.
This is a shame, in my opinion, because as Facebook is all about sharing data among friends, I think it adds a dimension to the ecosystem when apps can share (limited and reasonable) information among one another.
Thanks for the responses!
Related
I need to track unregistered users in my Django website. This is for conversion optimization purposes (e.g. registration funnel, etc).
A method I've used so far is using IP address as a proxy for user_id. For various well-known reasons, this has led to fudged/unreliable results.
Can I sufficiently solve my problem via setting a session variable at server-side? An illustrative example would be great.
For example, currently I have a couple of ways in my head. One is doing request.session["temp_id"] = random.randint(1,1000000), and then tracking based on temp_id.
Another is setting a session variable every time an unauthorized user hits my web app's landing page, like so:
if not request.session.exists(request.session.session_key):
request.session.create()
From here on, I'll simply track them via request.session.session_key. Would this be a sound strategy? What major edge-cases (if any) do I need to be aware of?
Cookies are the simplest approach, but take into consideration that some users can have cookies turned off in their browsers.
So for those users you can use javascript local storage to set some data. This information will get deleted once you close the browser, but it's ok for funneling purposes. Still others can have javascript turned off.
Another approach would be to put custom data(key) in every link of the page when generating the template. in other words you would have the session_id stored in html page and send through url parameters at click. Something similar happens with csrf token. Look into that.
I am fairly new in web development and I decided to handle a user's availability to send a POST request to server. However, I do not know even whether it is possible or not but when a user close my Django site without using logout button (For example close the browser or tab), in order to understand the user is offline or online, I want to send a request to server. As a result, when the server does not get an answer from the user for a while, it automatically logout the user.
Can you tell me is it a good way to handle a user's availability and first of all is it a realistic solution? If it is, can you suggest me a document or example that helps me please.
I agree to to the answer of #Mounir. That's not related to django, if you want to know when a user is "disconnected"(close the tab or window) you need to use javascript, in concrete you need to use Sockets.
I recommend you this ones:
http://socket.io/
https://github.com/centrifugal/centrifugo
I'm using centrifugo for one project right now. In concrete, for chat and inbox messaging. It's very simple to make it run with Django.
Greetings
For logging out user you can use the Session expiration, but for all other staff you want to achieve I don't see any thin really related to Django itself, everything depend on your requirements and is more Browser/javascript related than Django.
Currently I set up a RESTful API backend using Django and I can list a set of articles by the following GET:
api/articles/
Also, I can get a single article by:
api/article/1/
Each article is owned by a certain user, and one user could have multiple articles of course.
On the frond end side, I present all the articles at loading of the page, and I hope the user who is logged in currently could see the articles that they own in a different style, e.g, outlined by a box, and has a associated "delete" or "edit" button.
This requires me to tell, after the retrieval of the articles, which ones are owned by the current user programmatically. One way of doing this is to check the current user id with the owner id. However I feel this is not a good choice as the user id is the check is done fully on the client side and may be not consistent with the actual server judgement.
Therefore, is there a way, to tell by looking at the response of the GET, (say, let the server return a property "editable=true/false") to get whether the current user could edit(PUT) the resource?
I understand that this could be done at the server side, by attaching such a property manually. However, I am just asking whether there is better/common practice.
I just started learning web development and I am sorry if the question sounds trivial. Thank you!
You can attach propriety manually as you suggested. The advance of this approach is that you dont need any other http request.
Second possibility might be, that your client intentionally request information about endpoint permissions. In this case I would suggest to use OPTIONS HTTP method. You send OPTIONS HTTP request to api/articles/1 and backend returns wanted info. This might be exactly what OPTIONS method and DRF metadata were made for.
http://www.django-rest-framework.org/api-guide/metadata/
I think that this is a very interesting question.
Several options that come to me:
You can add to the GET api/article/1 response a HTTP header with this information i.e. HTTP_METHODS_ALLOWED=PUT,PATH,DELETE. Doing this way helps the API client because it does not need to know anything else. I think that this is not a good approach when more than one entity is returned.
call to OPTIONS api/article/1. Allowed methods for that user on that resource can be returned but notice that, in my opinion, this approach is not very good in terms of performance, because it duplicates the number of requests to the server.
But what if the entity returned also contains information on the owner or it? can, in this case the client know which policy apply and try to figure out it by itself? notice that the policy can be obtained from another endpoint (just one call would be needed) or even with the login response. If your entities do not contain that kind of information, it could be also returned as a HTTP header (like first option above)
I found that the cookie in browser is a random string which web server sends to each client for remembering users' information purpose. But I don't understand in programmers viewpoint, what does cookie use for?
For example, I've used EditThisCookie extension in Chrome Browser to read wikipedia.org site's cookie, in the following picture included here. The value of this cookie (sessionId) is useless for programmers (EDIT: I mean I don't extract any information from this cookie, I know the cookie is very important for web developers, so sorry about my poor expression). If I get this cookie, which kind of information I can understand about the users?
Looking for some help! Thank you very much!
The example about cookie
http://i102.photobucket.com/albums/m86/dienkun1/cookie_example_zps455f0dad.png
EDIT: Sorry, I've just expressed my problem in wrong way.
Actually, I am going to write an extension for collecting users' preferences via users' cookie, but I can't understand anything what information can be extracted from cookie. I've read about cookie in many documents, like wikipedia, and all of them just show how to get cookie, the definition of cookie, classified... and nothing about which information we can get from cookie.
Thank you very much!
Why do you say that the sessionId is useless for programmers? It actually can be extremely useful. Somewhere on Wikipedia's servers, they're probably storing quite a bit of information about your session. This could include things like whether you've already hidden one of their fundraising banners (so that it won't keep showing it to you again and again), to things that are required for basic functionality, such as what user you are currently logged in as.
However, Wikipedia is storing this same information for millions of sessions. It needs a way to tie the information back to each individual browser. That sessionId is how it does so. It set the sessionId in a cookie when you first accessed the page, and that cookie gets sent back to the server with every request you make to it now. Then they have code on the back end that reads that sessionId from the cookie and uses it to look up all of the information specific to your session, and do whatever needs to be done with it.
You could of course store the session information itself in the cookies, but there are a couple problems with that. First, there are limits on the size of each cookie, and on the overall size of all cookies for a single domain. Some of the data you want to store might not even fit. But the bigger problem is that cookies can be very easily manipulated by the end user. If you stored the information of who the user is logged in as in a cookie, the user could just change that value to something else, and suddenly be logged in as someone else! Of course, it's also possible that the user could change their sessionId to be some other user's session and suddenly be logged in as them. That's why session IDs need to be as random as possible, and should be long enough that guessing someone else's is basically impossible.
Well, why would someone bother writing a sessionId to a cookie if it's useless?
Cookies are extremely useful when it comes to (e.g) identifying users on your site so you can have them logged in right away, count their visits, track them on your site and even beyond.. only to name a few use cases.
To cite a somewhat popular site (wikipedia.org):
Cookies were designed to be a reliable mechanism for websites to remember stateful information (such as items in a shopping cart) or to record the user's browsing activity (including clicking particular buttons, logging in, or recording which pages were visited by the user as far back as months or years ago).
The most important word here is "stateful".
I have a page where user is asked only for the payment amount, then user will be redirected to another website where the payment will be processed, I want the amount to be set on the redirected page without using querystring,cokkie, etc..
I tried to use web service but here is my challange:
user enters amount on the website.
webservice is called and set the amount to ex:400$
then user is redirected without any query string to another website.
Now:
how this payment website will know that this user is the user entered 400$ on the redirecting page?
I can count on approaches more secure than this also.
thanks
I have made some research on net and asked my experienced friends, the answer is "impossible" this way.
Because redirected website somehow identify that user and there is no solution without querystrings or browser related components,
Here is my friend's advice and i am little bit satisfied, not totally :)
He calls this approach as ticketing,
First create a datetime.now integer, with that number add id and amount of money to be processed.
Then make a complex function to encrypt data. take square of every odd digit then divide to 7 etc.
then on the other website, decrypt data and check datetime if its within 5 minutes for example,
the link is valid.
You have to pass the data to the other website somehow.
Cookies wouldn't work due to domain restrictions.
Query string or form posts could work, but you don't want to use query strings.
Alternatively, if both sites share infrastructure, you could use that to share information - for example if they both have access to the same database, you could use that to share data (though you would still need to identify the specific user to both sites).
The way the service would have to work is to give back some token, probably a GUID, that the site will then look for in the querystring of an HTTP request, to identify the owner of that pre-populated data. You then tack that token onto your redirect, and the client makes a request that causes the payment site to go pull the pre-loaded data for that client.
You still have to use a query string, but now, the query string doesn't contain any human-consumable information; they can't identify their $400 amount in the query string and change it to a different amount of money. If they change the GUID at all, the request will most likely fail as that GUID won't exist in whatever datastore of pre-populated data exists behind the payment site.
Contact the website/web service/gateway. They will provide you the API which will define parameters and methods to accept payment amount. If you are the author of such service, provide mechanism to accept such parameters from your caller application. Communication should be secure, using SSL.
For example for payment gateway Paypal, check this for ideas:
Use of the PayPal payment system in ASP.NET
Have a look on wikipedia.
Shortly the answer is impossible this way, because somehow the redirect website should identify the user, all the ways are browser related or ip ( which can cause many issues later)