[El Forum]

[eluser]jedd[/eluser]
[quote author="tokyotech" date="1255915049"][quote author="trs21219" date="1255777774"]not really considering once it is accessed it is stored in mysql's memory (ram) until it expires in which case it is just re added to the memory[/quote]

I thought that requires Memcache. Will Apache cache database queries without Memcache?[/quote]

How is MySQL's query caching related to Apache?

[El Forum]

[eluser]BrianDHall[/eluser]
[quote author="tokyotech" date="1255774424"]Storing sessions in a database? This is outrageous. That's an additional disk access - 1,000 times slower than RAM access of a normal session variable.[/quote]

Um, no - on all counts. First of all if you are so concerned about performance you should read up on how sessions normally work in php: http://www.php.net/manual/en/session.installation.php

Note: By default, all data related to a particular session will be stored in a file in the directory specified by the session.save_path INI option. A file for each session (regardless of if any data is associated with that session) will be created. This is due to the fact that a session is opened (a file is created) but no data is even written to that file. Note that this behavior is a side-effect of the limitations of working with the file system and it is possible that a custom session handler (such as one which uses a database) does not keep track of sessions which store no data.

Unless you install shared memory functions and enable them, not storing sessions in the database is what generates additional filesystem activity.

As the PHP manual intones, not using a database to store sessions might actually be slower than the native implementation.

Also I don't see how you equate database access with filesystem accesses - MySQL uses as much memory as it does primarily to avoid disk access, and typically uses table caches in RAM to maximize performance.

Anyhow, it seems to me these aren't particular well researched or deeply held opinions - you just come off as unwilling to accept that CI requires only a few minor configuration changes to make it as secure as most people could ever want.

[El Forum]

[eluser]tokyotech[/eluser]
I was just asking questions to learn about CI and general facts about performance and security, not to purposely "stick it to the man". I have taken all your advice into account. Thanks.

[El Forum]

[eluser]tokyotech[/eluser]
[quote author="jedd" date="1255918992"]
How is MySQL's query caching related to Apache?[/quote]

I don't know. I was guessing. I suck at the whole architecture of web servers.

[El Forum]

[eluser]n0xie[/eluser]
[quote author="FernandoMM" date="1255745423"]
The CI implementation of sessions is horrible. It is extremely insecure.[/quote]
Can you elaborate on this? I have yet to see a more secure implementation of sessions, when used in conjunction with the database and an encrypted cookie, so I'm very curious how you would label this as 'extremely insecure' and 'horrible'.

[El Forum]

[eluser]WebsiteDuck[/eluser]
Sorry to bring up a 3 month old thread but I share the concern about CI sessions being insecure.

If you are not going to use encryption+database (which would be more secure) then you should just use PHP sessions.

In PHP sessions, an attacker can compromise one account by hijacking the sessionid, which is unlikely but not impossible. Data is stored server-side and cannot be changed by a user unless they have access to the webserver.

In the default CI sessions, any user can modify their cookie and change, for instance, their logged in username. This compromises every account.

Using CI sessions with encryption and database would be more secure though, I believe. This should make sessionid hijacking less likely.

So thats my two cents. Coders should not assume default CI sessions act like PHP sessions, or they risk being insecure. Feel free to correct me if I'm mistaken anywhere.