3 ms·

So if you look at the copyright, it was from 2005-2007: [https://github.com/opencats/OpenCATS/blob/develop/constants.php https://github.com/opencats/OpenCATS/bl

by twunde 6y ago

So if you look at the copyright, it was from 2005-2007: [https://github.com/opencats/OpenCATS/blob/develop/constants.php https://github.com/opencats/OpenCATS/blob/develop/constants....]. Maintaining and upgrading PHP from that long ago is a real challenge and typically involves several major rewrites of the core. For anyone reading through the code, this is where a significant portion of the code smell comes from especially since some of the updates were never finished (an example is that namespaces are setup to allow autoloading, but the files I looked at also had include_once in the files). The global $_SESSION['CATS'] is almost certainly from the 2005-2007 era. Then there is the faux security fixes (sprintf'd sql instead of parameterized queries.). FYI, the age of the codebase also explains why they're using MyISAM instead of InnoDB. This gives me flashbacks of early career codebases. I've seen so many of the mistakes here (including the HTML in the db. God, I remember the original dev being so proud of that mistake. 2 devs working on the same page? Who's going to overwrite the other's html?)

lucb1e 6y ago
> The global $_SESSION['CATS'] is almost certainly from the 2005-2007 era. How would you do it nowadays? I still write a lot of small scripts and rarely have more state to maintain for a user session than conveniently fits in PHP's session mechanism. It's usually $_SESSION['loggedin']=bool, ['userid']=x, and perhaps a few convenience fields that are shown on every page to avoid unnecessary database roundtrips like name and anti-csrf token. It's file-based so it probably doesn't work on multiple servers (I think you can also configure it to be database-backed, but from what I remember that's nearly as much work as just writing a proper solution yourself if you need that sort of scale), but until your software doesn't fit on a single, medium-beefy server anymore, is there an issue with this session global? (Assuming you don't have a runaway dev that thinks they need to replicate every vaguely user-related field into the session or something. I never saw that, but with php being a common beginner's language, I could see how some people here might have run into that or have a similar argument. I think you'd have issues with such a guy/gal no matter what.)
- twunde 6y ago
  It's much rarer to see $_SESSION or $_COOKIE nowadays. Most frameworks have session libraries that have some validation checks built in, handle csrf/flash messages and easily plug into backends (being able to have sessions use redis, etc in 2-3 lines of config makes session handling soooo much easier. And you're less likely to run out of disk space :P). The main issue with $_SESSION was that it is very easy to create a giant multidimensional array and have inconsistent logic creating fields. Another advantage is to bring the session variable in line with that of other languages so that devs switching languages won't be WTF as often

by twunde 6y ago

lucb1e 6y ago

> The global $_SESSION['CATS'] is almost certainly from the 2005-2007 era. How would you do it nowadays? I still write a lot of small scripts and rarely have more state to maintain for a user session than conveniently fits in PHP's session mechanism. It's usually $_SESSION['loggedin']=bool, ['userid']=x, and perhaps a few convenience fields that are shown on every page to avoid unnecessary database roundtrips like name and anti-csrf token. It's file-based so it probably doesn't work on multiple servers (I think you can also configure it to be database-backed, but from what I remember that's nearly as much work as just writing a proper solution yourself if you need that sort of scale), but until your software doesn't fit on a single, medium-beefy server anymore, is there an issue with this session global? (Assuming you don't have a runaway dev that thinks they need to replicate every vaguely user-related field into the session or something. I never saw that, but with php being a common beginner's language, I could see how some people here might have run into that or have a similar argument. I think you'd have issues with such a guy/gal no matter what.)

twunde 6y ago
It's much rarer to see $_SESSION or $_COOKIE nowadays. Most frameworks have session libraries that have some validation checks built in, handle csrf/flash messages and easily plug into backends (being able to have sessions use redis, etc in 2-3 lines of config makes session handling soooo much easier. And you're less likely to run out of disk space :P). The main issue with $_SESSION was that it is very easy to create a giant multidimensional array and have inconsistent logic creating fields. Another advantage is to bring the session variable in line with that of other languages so that devs switching languages won't be WTF as often