I'm building a PHP-based web app and am integrating a Flash-based charting engine. The Flash chart needs to make a AJAX request for its data. This request fails because it is seen as a new user agent and doesn't contain the PHP session cookie to identify it. So, it gets redirected to the login page.
I've read a few hacks to make this work, including supplying the session ID on the querystring, but that opens up security holes. How can I get Flash and PHP to share cookie-based session state automatically and stay secure?
In IE it will work naively. In firefox, the only way to achieve this is to POST the session id into the flash script (the php processor that is), and have it restore the session from that.
If the session cookie is initiated early enough, then it should be OK. I've had a similar problem with cookies shared between JavaScript AJAX and Flash requests (if you want to call that AJAX too, go ahead :-) ), and we solved them by making sure the JavaSCript finished the request that initiated the cookie early enough so that when the Flash sent the request, the browser already had the session cookie.
Also making sure the cookie path was set to "/" was a good idea.
That being said, if you can't get it to work - as dirkgently said - you can store the information in the HTML DOM using a JavaScript AJAX call, and then fetch it from the Flash object using an ExternalInterface call. But do make sure to set at least "allowScriptAccess=sameDomain" on your Flash object
You should be aware that transmitting a session ID in a Cookie: header, or in the argument field of the GET HTTP directive is of no different security.
Use ExternalInterface to talk to the Flex chart. Some browser related information can be passed around via the LoaderContext and BrowserManager classes as well. Dig in a bit into the AS3 documentation.
you can try and send to php 2 parameters one session_id and a second one that is an key that combines some information from the client ( ex ip ) and encrypt it with a key stored on the server and on the request from flash you check to see the second paramaters matches the client request, this way if somebody trys to do a session stealing they cant because they will not match the second param
Related
I'm trying to get all cookies of a website into an array in PHP. The goal of the script is to enter a website url and let the script check what cookies are set.
I've tried using HTTP_Request like this:
$req = new HTTP_Request($url);
$req->setMethod(HTTP_REQUEST_METHOD_GET);
$req->sendRequest();
$cookies = $req->getResponseCookies();
But this is only returning the server-side set cookies (like a session ID). I would also like to recieve cookies that are set with javascript, like the Google Analytics cookies.
I know this is possible because the website: http://www.cookie-checker.com/ is able to do so. To be sure the "cookie-checker" website is really parsing javascript set cookies and not just parsing known javascript source url, I've scanned a test website which wrote a dummy javascript cookie. They detected this cookie succesfully (incl. name, value and expiration date).
Any help would be very much appreciated!
Thanks in advance.
Barry
There is no way for a website to access cookies set by another site.
Browsers (have to) make sure this cannot happen.
What the site you mentioned does is make a request to the server and parse (also the javascript) its content.
What you will need to do is make sure that your script parses all the javascript and keeps track of cookies set using it.
The Google Analytics cookie is set by javasvascript and not in the response of the http request. It's impossible with HTTP_Request, it's impossible with PHP...
You need to have an javascript intepreter to get the cookie, or some headless browser (maybe Zombie.js?)
I am trying to read a cookie which I've set with javascript, jQuery Cookie Plugin specifically, and then after that I'm reading it with PHP to write it into a database.
For some reason the cookie is being created on page load, but doesn't "exist" until the page is refreshed. Which means that I'm pumping blank fields into my database tables.
The only way I can think of doing it is to AJAX out to a script which creates the cookie. Or ajax out to a script which returns the data to me in json.
The use case is that I'm creating a simple analytics class for an internal project, and I'd like to write into the database the users resolution, colour depth and all that jazz, which I'm using screen.width etc to get.
Cookie data are sent to the server (and forwarded to the PHP interpreter) when the client performs the request. Therefore, a cookie set by JavaScript on the client after the page has been requested from the server will not be transmitted until the next request to same server.
What you'll have to do is to perform some kind of request (could be done via AJAX) where a PHP script handles the incoming cookie information and stores it in the DB.
#jensgram is right. These two scenarios can happen:
User requests your page and (s)he hasn't the cookie. You render the response via PHP, but you can't see the cookie at server. Response gets delivered to the browser and on DOMReady (or events like that) you set the cookie. User sends another request (via interaction with your page). Here you have the cookie at server.
User already has the cookie (coming back to your site) and sends a request. You render the response via PHP, but this time, cookie is available in first shot. The rest is the same.
Two suggestions:
To prevent inserting null (or empty) values into your DB, first check to see if cookie exists or not. If not, simply try to set it.
For implementing Analytics, predefined patterns exist. For example, instead of setting a cookie, you can include your script on every page, and on load of each page, you can get the information you need, and send an asynchronous ajax request to your Analytics Collector PHP file. No need for cookie :)
There's an existing website written in PHP. Originally only the website existed, but now an Android application is being built that would benefit from re-using some of the PHP logic.
The PHP site was structured such that there are many pages that perform an action, set success/error information in $_SESSION, and then redirect to a visual page without outputting any content themselves. For example, there's action_login.php:
The page accepts a username and password (from GET or POST variables), validates the credentials, sets success/failure messages in $_SESSION, and then redirects to the logged-in homepage on success or back to the login screen on failure. Let's call this behavior the "HTML response".
The Android application will need to call the same page but somehow tell it that it wants an "XML response" instead. When the page detects this, it will output success/error message in an XML format instead of putting them in $_SESSION and won't redirect. That's the idea anyway. This helps prevent duplicate code. I don't want to have action_login.php and action_login.xml.php floating around.
I've read that the Accept Header isn't reliable enough to use (see: Unacceptable Browser HTTP Accept Headers (Yes, You Safari and Internet Explorer)). My fallback solution is to POST xml=1 or use {url}?xml=1 for GET requests. Is there a better way?
No frameworks are being used, this is plain PHP.
That's what the Accept Header is for. Have the Android request the page as application/xml and then check what was requested in your script. You might also be interested in mod_negotiation when using Apache. Or use WURFL to detect the UserAgent and serve as XML when Android.
I'd go with the android app sending a cookie for every request (really I would prefer the Accept header, but with the problems you pointed out with webkit I understand your reluctance to do so). The cookie simplifies the code server-side to not have to check for $_GET['xml'] or $_POST['xml'], and if some android user shares an URL of your application and it had a ?xml=1, the user who opens this in a computer browser would receive XML instead of the normal web output.
I wouldn't rely on $_SESSION for mobile applications because users (or at least I do) on mobile platforms tend to open your app, play 5 minutes, put mobile on pocket and 2 hours later return to your app. Do you want to set a session lifetime so long?
why not set a specific session for the app and then only set the header if the session is set something along the lines of
$_SESSION['app'] = "andriod app";
if ($_SESSION['app'] == "andriod app") {
header..
not really sure how to implement this into an app as I've done really little work with apps but hope this helps your thought process
I was going to ask about how to implement sessions in JS,I found few functions that can be used like this example I found :
String exforsys = request.getParameter("test");
session.setAttribute("test", exforsys);
And then just use session.getAttribute( exforsys);
But no response, I guess it's only used in servlets or something.
Anyway, I decided that maybe someone has an alternative way other than just use sessions, what am trying to do is click on a link in one page and depending on which link was pressed I will load different information.
Since its a onclick function, I'm stuck with JS!
So I need to pass this information to the second page, cookies works well cause it can be handled with both PHP and JS easily but some computers deletes cookies and that wouldn't be nice!
Any suggestions or other ways I can reach what I want but with out using sessions?
Sessions are server variables. Thus cannot be used by JavaScript.
However, you can retrieve the session variables, through ajax request.
Script (jQuery)
//This portion will be triggered once the DOM is loaded and is ready
$(document).ready(function() {
$.post("getsession.php",
{ "variable" : "yourneededsessionvariable" },
function(data) {
//data contains your session data
}
);
});
PHP
//getsession.php
<?PHP
session_start();
echo $_SESSION[$_POST['variable']];
?>
Use local storage or client controlled cookies.. Sessions uses server-controlled cookies. Cookies are just small files that resided on the client.
A session handle is stored in a cookie. If cookies are not accepted, the server will add the sessionID to the URL. If you do not have cookies, you cannot persist anything except in the url.
Why does "onclick" stop you from using sessions? You can ajax things to the server and add them to the session onclick
A session generally means "Some data stored on the server and associated with a user via a token stored in a cookie". You can't do that with client side JavaScript (for obvious reasons).
You could store data directly in a cookie.
If you are willing to sacrifice wide browser support, then you can get increased storage by using one of the client side storage mechanisms introduced by HTML 5 and Friends.
maybe someone has an alternative way other than just use sessions,what am trying to do is click on a link in one page,and depending on which link was pressed I will load different information.
Just link to different pages.
some computers deletes cookies and that wouldn't be nice
If they delete all cookies, then a session isn't going to work either.
Append the data you want the next page to get on the query string.
123
456
Then on foo.html you can inspect location.href to see what was passed in. THere is no need for cookies here.
PHP is a server scipring language while javascript is client end language
you cannot literally make sessions in javascript
Why not just use request parameters? i.e. http://yourserver.com/page.php?link=1
From a security standpoint, can someone give me a step-by-step (but very simple) path to securing an ajax call when logged in to PHP?
Example:
on the php page, there is a session id given to the logged in user.
the session id is placed dynamically into the javascript before pushing the page to the client.
the client clicks a "submit" button which sends the data (including the session id) back to the php processing page.
the php processing page confirms the session id, performs the task, and sends back data
I'm stuck on how (and whether) the session data should be secured before sending it through an ajax request. I'm not building a bank here, but i'm concerned about so many ajax calls going to "open-ended" php pages that can just accept requests from anywhere (given that sources can be spoofed).
PHP can get the session data without you having to send a session ID via javascript. Just use the $_SESSION variable. If you want to check if a session exists you can just do
if(isset($_SESSION['some_val'))
//do work son.
You'll need to use JavaScript to asynchronously pass user input back to the server, but not to keep track of a session.
Don't send your session data with javascript.
You don't need to (in most cases).
Just post the data with javascript and let PHP retrieve the session data from... the session.
Depends on how you setup your session data.
One simple example would be you have a session called username.
When PHP gets the request from javascript you can do: $_SESSION['username'] to retrieve the sessiondata.
This is a very simple example just to show how it can be done.
As noted above, you don't need to send any session identifiers out with your javascript, to the server an AJAX request is the same as any other request and it will know your session just fine. So basically, just don't worry about it, it's already taken care of.
It's another part of your question that worries me.
i'm concerned about so many ajax calls going to "open-ended" php pages that can just accept requests from anywhere
It worries me too; you shouldn't have any "open-ended" PHP pages hanging around at all. Every public .php script should have authentication and authorisation done. The easiest and most maintainable way to achieve this, IMHO, is to have a single controller script (e.g. index.php) that does authentication and authorisation then sends the request to an appropriate controller. Aside from this controller, all other scripts should be outside the document root so that they cannot be called directly.
This means that you only ever have to worry about authentication and authorisation in one place; if you need to change it, it only changes in one place. It means you don't need to worry about accidentally leaving some executable stuff in some library PHP file that's not meant to be called directly. It means you don't need to shag around with mod_rewrite rules trying to protect .php files that shouldn't be in the doc root at all.