If I have an app and it is run inside facebook. the first load I will get the
$_REQUEST['signed_request']
but if you click on any link inside my app and navigate within the app you will lose that $_REQUEST['signed_request'].
Is there any other way to know if my app is being run in a browser or inside facebook?
You can save value of signed_request in php session, something like this:
session_start();
if (isset($_REQUEST['signed_request'])){
$_SESSION['signed_request'] = $_REQUEST['signed_request'];
}
Later you can check if signed_request value is saved in session:
if (isset($_SESSION['signed_request'])){
//do something
}
You can continue to pass the signed_request around. Within your app, all your links should end with ?signed_request=<whatever> (or &signed_request=<whatever> if there is already a query string), and all your POST forms should include signed_request as a hidden input. Then you will always have access to signed_request.
If you really only need to know whether your app is being accessed through Facebook, the simplest way is to use a unique url in your app settings -- either a unique hostname like fb.yoursite.com, or a unique directory name like www.yoursite.com/fbapp/ . Then you configure your server so the unique hostname/directory points the same place as the regular hostname/directory. That way the same files can be reached either way, but your scripts can check the $_SERVER info to tell whether it's a Facebook request.
HOWEVER...unless you are strictly dealing with non-authorized access, you have to consider whether that will really solve anything. If you have to "detect" things like this, you must not be carrying any persistent state info, and your user will lose his "identity" as soon as he goes to page 2. So most likely, what you need to be considering is not a way to tell on each page whether the user is in Facebook, but rather a way to parse all the info you need on the first page and then make that available in all other pages. Many people use PHP sessions for this. Personally I think that's a bad idea, and would do something more like what Ben suggested in his answer (using GET and POST to pass the info you need).
Personally, a very simple yet effective solution I've used is some client side javascript (which can obviously be disabled etc) - this works nicely for a simple redirect and it won't work in every case.
// Redirect if the page is not an iframe
if (window.location == window.parent.location){
window.top.location = '{{ facebook_tab_url }}';
};
Related
I searched everywhere but it seems impossible thing to do.
I was able to catch SwitchEvent coming from SwitchEventListener and get both impersonator and target user objects (one being impersonated as) but I would really like, based on target user roles to redirect request to some other URL.
Example:
I have two restricted areas: "/basic" and "/elevated" where first one requires ROLE_BASIC and the other one ROLE_ELEVATED role. Now, if I am currently logged in as ROLE_ELEVATED user and want to switch to some ROLE_BASIC user using URL:
/basic/?_switch_user=some_basic_user
that would result in AccessDeniedException, and I'm forced to navigate first to:
/?_switch_user=some_basic_user.
Only after that I can navigate to /basic as token has been written to session.
Now, the question, as subject suggests: Is there any way to redirect user using SwitchEvent (or any other) after doing user switching?
Ok, I finally got access to my dev computer and looked up the the solution to this problem.
And, I got to say, it is not as clean as I wanted it to be but delivery date was critical and this was the only way to achieve it back then.
So, what I basically did was to send AJAX (although, I set async to false) request to URL /?_switch_user=some_basic_user, wait for an answer and if it was successful I would navigate forward to /basic/?_switch_user=some_basic_user URL. I know, it's quick and dirty, and is pretty much unreliable...
Hope this helps....
You can just generate the right link to begin with:
...
Of course, the URL can be generated by twig's path helper too:
...
i've a jquery script which post/get data to .php script. but i wanna prevent direct access to the php script. for example if the user look at the html source code,they will be able to access the php script directly by copying the url from the js file and i dont want that. how do i prevent users from doing that?? i want the user to use it via the html UI. i've google but found no link on this. however, i did notice that some popular websites are able to do that. how should i go about doing this??
It seems like a simple redirect is what you're looking for here.
Add something like this to the top of your php file. This will prevent the page from being accessed if the proper post has not been made. Of course you'll have to change the post and redirect to content more relevant to your project.
if (!isset($_POST['data'])) {
header('Location: your-redirect-location');
}
You may also be able to redirect based on the $_SERVER['HTTP_REFERER'] variable.
EDIT: I was going to explain this in a comment but it's too long. I should note that this is a simple solution. It will keep people from accidentally accessing your script. It's really difficult to create a 100% secure solution for your issue, and if somebody really wants to access it, they will be able to. If you don't have anything secure in the script in question, this will be fine. Otherwise, you'll have to look for an alternative.
Here is one solution:
<?php
if(isset($_POST["post_var]))
{
//to the code you want to do when the post is made
}
else
{
//do what you want to do when the user views the post page
}
?>
how do i prevent users from doing that?
You can't - all you can do is mitigate the risk people can fiddle with your script. Making sure you have the right HTTP_REFERER and/or POST data are both useful in that regard: a "malicious" user would need more than pointing her browser to the URL.
More techniques can be used here:
using session variables: you might not want users that are not logged in - if applicable - to use the URL.
using a one-time challenge (token): you can place a value in the HTML page and have the JS code send this value along with the POST request. You store this value in the session when it is generated. Checking the POSTed token against the session token guarantees the user has at least "seen" the HTML page before submitting data - this can also be useful to prevent duplicate submissions.
However, remember that anything a browser can do, people can do it as well. All these techniques can prevent the curious from doing harm, but not the malicious.
All you can do is making sure nobody can really harm you, and in this regard, your Ajax URL is no different than any other URL of your site: if it's publicly reachable, it has to be secured using whatever technique you already use elsewhere - sessions, user rights, etc.
After all, why should you care that users use this URL not using a browser ? You might want to think of it in terms of an API call that, incidentally, your page happens to use.
Your problem is similar to and has the same problems as a cross site request forgery.
To reduce your risk, you can check the request method, check the referrer, and check the origin if set. The best way is to have a secret token that was generated on the server that the client transmits back in every request. Since you're dealing with friendly users who have access to your live code, they may be able to debug the script and find the value, but it would only be for one session and would be a real hassle.
I'm making a PHP app to allow our customers to retrieve information from our database, using pre-defined functions. Perhaps PHP isn't the best choice for this, but the same page is also used as a backend for a flash app, and we don't have the time to rewrite it in another language (still, if we did have that time, I'm open to suggestions).
They will access the page via a URL, something like:
http://myurl.com/test.php?function=getUser&username=John
This will call the function getUser($username) and pass the value John as the $username parameter. Here's the twist: this page will be called from an application that the customer creates, not from a browser.
They are allowed to get info about some users, but not others. To enforce this, I require them to provide login information. I'm not sure how I can keep that user logged in so that they don't have to pass their login information every time they call a function, which can be multiple times per second.
I don't think I can use sessions or cookies, since they are not calling the page from a browser. So how can I keep that user logged in?
You can look into setting up something like a SOAP API on your end. Then, you can provide them with a token that goes back and forth (and possibly changes) between each request they make.
Have a read over SOAP and see if it gives you any inspiration at the very least. As far as implementing it, your options are many. Maybe consider using a framework?
You've hit the stateless wall :D .
You will either need to create a session aware browser client object with some library or some token exchange. But as long as you are using a separate session between calls you will need to hit the database again to authorize the user; token or not.
Simple answer: You can't, since HTTP is stateless.
But: You can use the same principle as cookies do, which is "send some authentification info along with the request without transmitting the secret". Have a look into OAuth and if it fits into your scenario. You can even use ready-made libraries for PHP.
I am installing an application inside of a Facebook page. I received the signed_request variable in my $_REQUEST, or when using the Facebook PHP SDK Facebook::getSignedRequest() function. However, inside my application when I go to a different page within the application, the signed_request does not follow it.
I understand that it is placed inside the $_SESSION and the signed_request data is stored inside the session, but what method am I supposed to be calling in order to get that data? Do I have to strip it out of my session myself and not use the PHP SDK? I would expect getSignedRequest to always give me the same result as long as I am receiving it in the $_REQUEST or through the $_SESSION.
Please advise! Thanks in advance!
I believe the issue here is with third party cookies and it's something I've come across a lot.
The way I have solved it in the past is to check on initial load for the signed request and if present, append the raw signed request data to a query var on all links (i.e. http://www.example.com/page&signed_request=<<signed_request>>)
It's not pretty but your urls are hidden from view as they are in the iframe - it's not something I would advise to do if your application isn't inside an iframe.
You will also need to check any Javascript or server side code that may affect data inside the request and amend your urls accordingly.
I hope there's a better way of working than this, but it's the only way I've figured out so far (without resorting to using the app_data query var on facebook urls for navigation).
How about saving the signedRequest in a Session and reusing it?
$signedRequest = $facebook->getSignedRequest();
if(isset($signedRequest)) $_SESSION['signedRequest'] = $signedRequest;
else $signedRequest = $_SESSION['signedRequest'];
Almost everything is in the title :
Here's what I'd like to do :
A nice html page with a php authentication process (http first then https & so on)
Launch a flex app which knows (I don't know how (this is the actual question !)) the user has already been authenticated and display his/her stuff he/she has to do for the day (or whatever...).
Of course if someone try to call directly the flex app I would display an "authentication error" message and then redirect to the authentication page.
I'm sorry for my English which is perfectible.
I was thinking about the session cookie : first authenticate then ass a variable on the server side, something like :
$_SESSION['authenticate']=true
Then, on the flex side, just send the cookie and ask if the user is properly authenticated, something like calling a php web page like :
https://is_authenticated.php?php_session=xxxx
Thank you
Olivier
What are you using on the server side? Remember that you shouldn't do anything in the flex application other then send the SESSION ID along with any requests. Any time where the client checks security, you have a bug. The server must validate the session and determine if the request is allowed.
It sounded in your last comment that you are worried about people manually calling a web page. Each page must check to see if the user is authenticated. I don't know your specific application, but you may try looking at AMFPHP and see how they do session authentication. Good luck!
Your on the right track!
You could use session-authentication, these links might help you out:
http://www.zend.com/zend/spotlight/sessionauth7may.php
http://www.tizag.com/phpT/phpsessions.php
There is also the possibility to use http-authentication
http://se2.php.net/features.http-auth
however http-authentication is not as flexible as session-authentication, and also means some more configuration on the serverside.I would therefore recommend you to stick with sessions.
This is exactly what I would do.. A few things to consider from a security standpoint:
If your php service (from flex) gets an unknown session token, always generate a new one. This also applies to your PHP application and is often overlooked.
I would generate the swf with javascript, and manually insert the session cookie using javascript. This way people won't download and safe (or cache) your php pages with sessions that are invalid in the future.
Even better would be to use a separate token other than the session, and on the server figure out what the session id was based on this flex token.