Client Updater on 1.0.1

[naeren]

Hopefully I’m on the right track and not way off base doing completely unneeded things, but I’m having trouble with the Client Updater and here’s what I’ve encountered so far.

After uploading a module through the web interface, I’m able to query [SIZE=3][url]http://fogserver/fog/service/updates.php?action=list[/url][/SIZE] and return the base64-encoded name of the module, in this case R3JlZW5Gb2cuZGxs (GreenFog.dll).

On the client computers, the FOG program then passes this encoded name back to the server for the md5, so if I make another query using this to [url]http://fogserver/fog/service/updates.php?action=ask&file=R3JlZW5Gb2cuZGxs[/url], it returns nothing.

Looking at updates.php, it doesn’t decode the filename before checking the database. So if I add that to line 9 like this (and on line 14 for the action=get request):
[CODE]foreach($FOGCore->getClass(‘ClientUpdaterManager’)->find(array(‘name’ => base64_decode($_REQUEST[‘file’]))) AS $ClientUpdate)[/CODE]
I’m able to retrieve the md5 successfully.

However, I don’t think the file is being uploaded correctly in the first place. In my database in the row for the update file, ‘cuFile’ is ‘phpFuqebn’, what I’m guessing is the temporary file upload name? Is that where the file data is supposed to be? Because if I query [url]http://fogserver/fog/service/updates.php?action=get&file=R3JlZW5Gb2cuZGxs[/url], it comes back as a 6 byte base64_decoded file (per line 20 in updates.php). If I encode it back, I get ‘phpFuqebn’, as expected.

[Tom Elliott]

The actual file should be stored directly in the database table as a blob.

I’ll take a look and see if I can get anything for you though. As I agree, I don’t think it has been working properly yet.

[Tom Elliott]

This should now be fixed in SVN 1724

[naeren]

Thank you very much, Tom.

I made the following edits to lib/pages/FOGConfigurationPage.class.php on lines 544 and 552 and the file now successfully saves to the mysql database. For a new module, it was saving the temporary filename to the database as cuFile. When updating an existing module, basename() would cut off most of the uploaded data. The data isn’t encoded, so if you want that you’ll need to add the decode function back into service/updates.php line 20.

I’ve tested it and it’s back to working perfectly! Thanks again.

[CODE]diff ~/fog_r1724/packages/web/lib/pages/FOGConfigurationPage.class.php lib/pages/FOGConfigurationPage.class.php

544c544
<->set(‘file’,basename(file_get_contents($_FILES[‘module’][‘tmp_name’][$index])));

->set(‘file’,file_get_contents($_FILES[‘module’][‘tmp_name’][$index]));
552c552
<‘file’ => basename($_FILES[‘module’][‘tmp_name’][$index]),

---

‘file’ => file_get_contents($_FILES[‘module’][‘tmp_name’][$index]),[/code]

[Tom Elliott]

[quote=“naeren, post: 27989, member: 24314”]Thank you very much, Tom.

I made the following edits to lib/pages/FOGConfigurationPage.class.php on lines 544 and 552 and the file now successfully saves to the mysql database. For a new module, it was saving the temporary filename to the database as cuFile. When updating an existing module, basename() would cut off most of the uploaded data. The data isn’t encoded, so if you want that you’ll need to add the decode function back into service/updates.php line 20.

I’ve tested it and it’s back to working perfectly! Thanks again.

[CODE]diff ~/fog_r1724/packages/web/lib/pages/FOGConfigurationPage.class.php lib/pages/FOGConfigurationPage.class.php

544c544
<->set(‘file’,basename(file_get_contents($_FILES[‘module’][‘tmp_name’][$index])));

->set(‘file’,file_get_contents($_FILES[‘module’][‘tmp_name’][$index]));
552c552
<‘file’ => basename($_FILES[‘module’][‘tmp_name’][$index]),

---

‘file’ => file_get_contents($_FILES[‘module’][‘tmp_name’][$index]),[/code][/quote]

Thank you much for the information, but I need a little clarification.

The edits I made to updates.php added a base64_decode. I then tested the update module and all seemed to return. Go to the link also returned with the filename.

So do we need the base64_decode in updates.php with the above updates?

[naeren]

It depends on if you wanted to store the file contents in the database in an encoded format. I only mentioned this because before revision 1724 updates.php was trying to decode it when retrieving the file but FOGConfigurationPage.class.php never encoded it when it saved it.

As of revision 1726, the file is not encoded when its stored, but it is decoded when it’s retrieved, so it corrupts the file. Either FOGConfigurationPage.class.php lines 544 and 552 will need to encode the data before it’s stored, like:
[code]->set(‘file’,base64_encode(file_get_contents($_FILES[‘module’][‘tmp_name’][$index])));[/code]

or updates.php line 20 will need to have the decode statement removed from it:
[code]print $ClientUpdate->get(‘file’);[/code]

but only one of those options. Sorry for the confusion!