Forums

Uploadify & CONCRETE5 Session Problem, Authenticating File Submission

Permalink
Hello. Here's my problem.

I am using Uploadify script for an add-on I am developing. I need to securely authenticate the upload, and it seems like the best solution to use is SESSION. I am sort of new to this so if there is a better way please let me know.

I have closely followed this guide as provided from Uploadify:
http://www.uploadify.com/documentation/uploadify/using-sessions-wit...

It does not pass the value $_SESSION['uploadToken'] set by my page with the upload. I have literally only seen it pass over all the values ONCE and I didn't touch anything that time. The next page load it went poof.

Here's my Uploadify $_POST options:
'formData'     : {
            'method'   : 'post',
            'session' : '<?php echo session_id();?>',
            'token'     : '<?php  echo $token ?>',
            'gallerySet' : gallerySet
         },


Here's the only thing I see on the uploadify.php side:
Array
(
    [uGroups] => Array
        (
            [1] => 1
        )
)


Here's what shows up in the dashboard page that is sending the request (and these values should all be passed, but aren't):
Array
(
    [uGroups] => Array
        (
            [1] => 1
        )
    [:1;s:1:"1";}:1:"1";uName] => admin
    [superUser] => 1
    [uBlockTypesSet] => 
    [uTimezone] => 
    [uDefaultLanguage] => 
    [uOnlineCheck] => 1383314290
    [uLastOnline] => 1383314276
    [dashboardHasSeenImage] => 1
    [uploadToken] => 670961c81d9e56c8dfd854f4d796e331
Viewing 15 lines of 35 lines. View entire code block.


I have this snippet of code in my header of the dashboard page to generate the token:
<?php  defined('C5_EXECUTE') or die(_("Access Denied.")); ?>
<?php 
$token = $_SESSION['uploadToken'] = md5(uniqid(mt_rand(), true));
Loader::helper('concrete/interface');
Loader::model('file_set');
$form = Loader::helper('form'); 
$ih = new ConcreteInterfaceHelper();
$help = 'Upload your images here, either one by one, or in bulk.';
echo Loader::helper('concrete/dashboard')->getDashboardPaneHeaderWrapper(t('Upload/Create'), t($help), 'span12', false);
?>


Then, I have this code which i've tried various ways in the uploadify.php. It also finds the same session without this code, so I know the session is being passed to this file regardless of this code or not (the result is still the same, only 1 value in SESSION) This particular way (which is copy-paste from the uploadify site) fails and exits the script. I modify it to change to $_POST['session'] and it gives me the same result (only uGroups showing up)
$session_name = session_name();
   if (!isset($_POST[$session_name])) {
       exit;
   } else {
       session_id($_POST[$session_name]);
       session_start();
   }


So, how can i get uploadToken (and im assuming all other values) to pass to uploadify.php? It seems like they are always lost, except for that one random time where they all showed up, but then disappeared.

Any help greatly appreciated. Thank you.
emirii
 
emirii replied on at Permalink Reply
emirii
I've narrowed it down to a Firefox only problem. Running most current Firefox.

Still researching the problem. It works the first time I log in and then stops after the 2nd or 3rd+ upload.

Super annoying.
emirii replied on at Permalink Reply
emirii
Continuing to experience problems with validation and Firefox.

Chrome/IE does not work with validation but the form won't even submit in Firefox without asking me to login.

On the 12th hour trying to sort this out and im about to scrap my whole project :(
JohntheFish replied on at Permalink Reply
JohntheFish
Your work with MD5 etc is already available in a helper integrated to the core.

Have a look at
http://www.concrete5.org/documentation/how-tos/developers/use-token...
emirii replied on at Permalink Reply
emirii
Thanks, I've finally got to the point where I am fully using the C5 authentication token helper!

One snag, It still won't work in Firefox!

Chrome and IE both accept the token as valid and the images are uploading. However in Firefox the token is not being accepted.

Here i have the value that passes through $_POST in javascript call:
'ccm_token'     : '<?php  $vt = Loader::helper("validation/token"); echo $vt->generate("uploadify");?>',


Here is my authentication:
$val = Loader::helper('validation/form');
   $data = $_POST;
   $val->setData($data);
   $val->addRequiredToken('uploadify');
      if ($val->test()) {
                   UPLOAD!! Chrome & IE reaches this step
                } else {
                   FAIL!!! Firefox reaches this instead.
                }


I've never encountered a problem like this, especially since i'd presume it to be server side. I am going to try a different server soon.
JohntheFish replied on at Permalink Reply
JohntheFish
The network tab of Firebug will tell what is actually being sent.u
JohntheFish replied on at Permalink Reply
JohntheFish
The network tab of Firebug will tell what is actually being sent.u
emirii replied on at Permalink Reply
emirii
Hey there. A tiny bit confused at what i'm looking at here, but I've pulled some raw header infos from both browsers.

Firefox (not uploading):
HTTP/1.1 200 OK
Date: Sat, 02 Nov 2013 04:54:43 GMT
Server: Apache
X-Powered-By: PHP/5.2.17
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 54
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html
Failed to authenticate. Reload the page and try again.


Here's Chrome:
HTTP/1.1 200 OK
Date: Sat, 02 Nov 2013 05:01:04 GMT
Server: Apache
X-Powered-By: PHP/5.2.17
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 83
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
Content-Type: text/html
File "<b>ffximegfarhappy.jpg</b>" uploaded to gallery "<b>Plants</b>" successfully
JohntheFish replied on at Permalink Reply
JohntheFish
I was pecking at a mobile phone last night, so didn't give much explanation.

You are almost looking at the right thing - you are looking at the response header - you want to look at the associated request side of the same transaction between browser and server and see what post/get parameters are passed from the browser to the server.

That will confirm whether or not on firefox is passing the token with other data.
JohntheFish replied on at Permalink Reply
JohntheFish
Just some wild ideas. You could try some variations of the javascript creating the token.

var uploadify_token = '<?php  $vt = Loader::helper("validation/token"); echo $vt->generate("uploadify");?>';
// or
var uploadify_token = "<?php  $vt = Loader::helper('validation/token'); echo $vt->generate('uploadify');?>";
// then later (no quotes round ccm_token )
{
ccm_token : uploadify_token,
...
...
}


Also, when you validate the token in php, you can try dumping the request parameters to the log.
http://www.concrete5.org/documentation/how-tos/developers/concrete5...
emirii replied on at Permalink Reply
emirii
Here's the request being sent. This looks the same in all browsers and only fails in Firefox.
Array
(
[Filename] => 90e060c2cf6d58d1fcc17c032a0bbff6.gif
[gallerySet] => 6
[method] => post
[ccm_token] => 1383529302:4817c97874370b4fcd62287697552459
[Upload] => Submit Query
[CONCRETE5] => 001005540e8d08f0c7888ccf9089dbc9
)


View source shows the token, but it doesn't match the ccm_toke in in post (is it supposed to?)

On another note, if i stick all this uploadify stuff into controller.php (if it's possible) would validation be an issue anymore?

Thank you.
emirii replied on at Permalink Reply
emirii
I have let uploadify go. This must be caused by firefox+flash player.

In this day, I have chosen to go with a HTML5+jquery uploader that passes the token without a hitch.

I guess IE 7,8 & 9 users will have to use the C5 uploader ;)
JohntheFish replied on at Permalink Reply
JohntheFish
Thats really up to the core team. What they didn't like was the security hole Uploadify created. If the security hole was fixed, then maybe uploadify would be OK. So it all depends on whether adding the token fully fixed all uploadify security holes.

Anyway, uploadify is now an academic issue as you have moved to an alternate solution. For testing, you need to see if you can spoof it into uploading without passing security checks like it was possible to do with uploadify.