| Author |
Thread Statistics | Show CCP posts - 2 post(s) |

Solo Drakban
GoonFleet GoonSwarm
|
Posted - 2008.12.15 16:59:00 -
[1]
This looks like an excellent application, good work! I am currently looking at adapting the authentication system to be compatible with the SSO system used by GoonSwarm so look forward to having a few thousand users suddenly submitting feature requests and bug reports. ;)
A few suggestions from the overly paranoid:
- Your are only doing a single MD5 hash of the password variable when setting the cookie. You might want to consider adding a random salt value to this md5 sum either on a per-user basis (stored in the DB in the user table) or globally (defined value in the config.php). Rainbow tables make unsalted MD5 hashes trivia to reverse. While this won't prevent access to OOE if somebody manages to get the cookie values it will protect the users from themselves if they've used their OOE password someplace else (like their EVE login) something that happens all to often unfortunately.
- You might want to consider using a database abstraction layer like ADODB or MDB2 or moving to the MySQLi PHP interface and run all of your DB queries through a prepare/bind/execute cycle to further protect against SQL injections. I notice that you are escaping user input which is good but this would just add an extra layer of protection.
As I said, comments from the overly paranoid but I've had to become so running things for GoonFleet. Feel free to ignore me.. ;)
Keep up the excellent work!
|

Solo Drakban
GoonFleet GoonSwarm
|
Posted - 2008.12.18 00:41:00 -
[2]
Edited by: Solo Drakban on 18/12/2008 00:41:29
Quote: PDO PDO supportenabled PDO drivers sqlite, sqlite2
Edit - I think my problem is that while PDO is installed, it's only setup for sqlite and sqlite2, not mysql. I'm just guessing at this point... I'll contact my hosting provider to see if they can enable it though.
This is correct. PDO support for MySQL needs to be enabled at compile time adding the --with-pdo-mysql flag to the ./configure stanza when starting a source compile of PHP or compiled into the PDO module if the PHP installation is modular.
|

Solo Drakban
GoonFleet GoonSwarm
|
Posted - 2008.12.19 17:58:00 -
[3]
Originally by: Adira Deimos Azazel,
Any chance of this awesome tool being done without requiring the PDO mySql driver? (My hosting company won't install the required driver. It seems their on Debian, and claim the PDO mySql driver isn't compatible with their shared hosting architecture.)
That's a complete load of bunk. Unless they somehow don't support MySQL at all via PHP in which case you really really need to look for another host. In fact, given their response above you should look for another host anyways.
|

Solo Drakban
GoonFleet GoonSwarm
|
Posted - 2008.12.31 15:52:00 -
[4]
Edited by: Solo Drakban on 31/12/2008 15:54:50 Well I've installed this for GoonFleet and we've been testing it out. I'm running 1.5-QR under PHP 5.2.8 (fcgi), MySQL 5.1 and Lighttpd. A couple of things to note:
First, this produces a ton of warnings in the error logs. See:
Originally by: Error Log
[31-Dec-2008 09:52:33] PHP Notice: Undefined offset: 16594 in /nfs/webroots/gs-apps/public_html/outofeve/includes/eve/apiChar.php on line 255 [31-Dec-2008 09:52:33] PHP Notice: Undefined offset: 3444 in /nfs/webroots/gs-apps/public_html/outofeve/includes/eve/apiChar.php on line 255 [31-Dec-2008 09:52:33] PHP Notice: Undefined offset: 18580 in /nfs/webroots/gs-apps/public_html/outofeve/includes/eve/apiChar.php on line 255 [31-Dec-2008 09:52:33] PHP Notice: Undefined offset: 3447 in /nfs/webroots/gs-apps/public_html/outofeve/includes/eve/apiChar.php on line 255 [31-Dec-2008 09:52:33] PHP Notice: Undefined offset: 16596 in /nfs/webroots/gs-apps/public_html/outofeve/includes/eve/apiChar.php on line 255
These seem to appear doing just about anything.
Secondly, I noticed that your application seems to assume in some places that it will always get valid data from the API. My proxy was missing a couple of the newer API calls (such as medals and factional warfare stuff) and instead of producing an error it tried to carry on with invalid data and produced a blank screen with entries in the error log about missing and undefined objects.
I also noticed that the market data cache system doesn't appear to attempt to create the 'market' directory inside the defined cache directory which results in a lot of these errors in the logs:
Originally by: Error Log [31-Dec-2008 01:45:40] PHP Warning: touch() [<a href='function.touch'>function.touch</a>]: Unable to create file /nfs/webroots/gs-apps/var/ooe/cache/market/8b4c03d1ed382ff417879ca92beb67a0 because No such file or directory in /nfs/webroots/gs-apps/public_html/outofeve/includes/eve/apimarket.php on line 60
Creating the directory and making it writable to the webserver corrected this of course but it's not mentioned in the documentation so I assumed that the module should have created it at some point.. :)
I'm also sorry to report that it doesn't react well to a huge corporation.. :( The Asset list for corporation won't load for GoonFleet due to memory allocation limitations. I have PHP allowed to use up to 128MB of RAM per instance but apparently that's not enough. As an experiment I bumped it up to 256MB but it still failed. Perhaps some sort of paging system for the data? :)
All in all however it is a great looking application and if you're interesting in looking at any of the bugs I've outlined about or working on the memory stuff please feel free to contact me and I can do 'live' debugging for you.. :)
Thanks!
Edit: Oh yea, I forgot to mention that this installation is front-ended by lighttpd with separate load-balanced FastCGI PHP application pools so Apache is definitely not required.. :)
|

Solo Drakban
GoonFleet GoonSwarm
|
Posted - 2009.01.01 01:14:00 -
[5]
Originally by: Rilwar Your error log prompted me to check mine as well, but is empty. I don't have extensive knowledge of everything HTTPD/PHP related, but I'm wondering if maybe fcgi is the culprit there? I'm using PHP 5.2.6 without fcgi, so there's very little disparity between our versions.
-EDIT What version of fcgi are you running, and *nix/Win32? I'll try installing fcgi on my copy to test that theory, as I'm assuming doing the reverse on your systems would be much more hassle than it's worth to see if it is in fact the problem.
I highly doubt it's fcgi. There really isn't any difference between FCGI and mod_php other than one is handled internal to the webserver and the other is handled external. If you really want to know the FCGI pool is running a separate server. It's PHP v5.2.8 running in an FCGI pool listening on a socket. The FCGI spawner is the spawn-cgi system (and scripts) that come with lighttpd slightly modified to allow for separate php.ini's for each FCGI pool. The front-end webserver is lighttpd. The web directories are mounted via NFS from a third server and the pathing is identical on both front and back-end servers to avoid any possible pathing issues.
Originally by: Rilwar Also, if you've not looked @ index.php - Theres a commented line to add Query/Execution data, check what that gives you, I'm curious as to what GF's memory usage might be if my little alt corp with no starbases uses 4MB to hash out the starbases module.
I can't even run a GF starbase report without 'priming' the cache first, the 45 execution time limit is reached by PHP due to the time the EVE API system takes to respond to each query. After I manually (well, with a perl script) 'prime' the proxy cache the stats are:
Processed in 2.5662 seconds, 389 queries, 13307.05kb memory used.
I cannot hit http://apps.goonfleet.com/outofeve/?module=corporation or http://apps.goonfleet.com/outofeve/?module=assets&corp=1 without running into RAM limitations.. :) I'm afraid to even attempt to hit the 'killboard'.. ;)
I can't really fault the application though, GF is rather a beast until itself.. :)
|

Solo Drakban
GoonFleet GoonSwarm
|
Posted - 2009.01.01 02:28:00 -
[6]
Originally by: Helena Shun Concerning all the Notices, just add the following line in index.php
error_reporting(E_ALL & ~E_NOTICE);
That's should "fix" them.
No, that will just mask them. If I wanted to just mask them I would have already done this and not posted about them being an issue.
|

Solo Drakban
GoonFleet GoonSwarm
|
Posted - 2009.01.11 20:08:00 -
[7]
Originally by: Helena Shun Note that notices in PHP are just that... Notices... they do not affect the functionality of the application in any way, they just warn the coder that a possible issue may be present in their program (if the said behavior is unintended). Notices should be disabled on a production server. For development, you leave them on, not on production.
Notices should absolutely be on in a production environment, but like all other messages should be logged to a file and not displayed to the end user. Anything generating a notice (or warning) should be addressed by the developer so the application does not throw the notice or warning at all. Even if they are just cosmetic they are an indication that the application is doing something wrong or looking for data that does not exist. I relate notices in PHP to warning in perl. They are mostly harmless but a good idea to make sure they never happen if for nothing other than to maintain good coding habits.
|

Solo Drakban
GoonFleet GoonSwarm
|
Posted - 2009.03.17 18:07:00 -
[8]
Does development on this application continue?
|
| |
|