Asked  2 Years ago    Answers:  5   Viewed   82 times

As the title says, are there limits (if any) for session variables or they're considered as usual variables and can store equal amount of data?

I'm looking if there are any other limits aside from variable type ones like max length, max values and so on.

P.S. If the question is unclear, please let me know.

Thanks in advance!



As @Thariama said, there's no limit on the number of variables; also, there's no limit on the amount of data you can store in a session (I've seen sessions tens of MB in size).

As the size of a session gets larger, you'll run into various quirks though: PHP 5 deserializes the whole session into memory at session_start() (using the default session handler - you can make you own solution, of course); with a 20 MB session and 50 concurrent users, your scripts start to be severely limited by disk access speeds (a.k.a. "script startup is slow as molasses" - the sessions alone would be hogging a GB of RAM); in the end, we dedicated a box to keep as many sessions as possible in its RAM, and the frontend boxes accessed them over NFS (although it helped in our case, this may be overkill for you).

Note that for many concurrent users and session storage on disk, the number of session temporary files may cause problems with filesystem limits (e.g. how many files can be in one directory before you run into problems with stat() performance), or other limits (we once found the hard way that a box was configured to only allow 4096 open files at the same time). None of this is really session-specific, but can be triggered by session handling.

Sunday, September 18, 2022

The behavior you describe opposes the concept of a browser session. Why would a user want more than one session? Is it a matter of user access controls needing to be enforced? If so, assign users to logical groups and grant permissions to specific groups. Do users need to perform some action on behalf of other users? If so, design the website around that concept instead of trying to create multiple sessions for a single user.

If you really have to do this, you could do something horrible like pass along a query parameter (very insecure!) between pages to act as a session ID, bypassing the actual $_SESSION altogether and managing your own concept of a session. Again, this is not normal and will only lead to headaches/security issues in the future.

Wednesday, October 26, 2022

My suggestion from your previous question still stands: please compare session ids.

The solution might be as simple as your browser not accepting session cookies.

You retrieve the session id by calling session_id(). Do that right after session_start() it should give you a constant value if the session is the same. Otherwise for every request a new session is instantiated.

Also check C:wamptmp. A gazillion files in this directory might indicate fresh sessions for each request.

EDIT Since we've confirmed new sessions per request, it's time to find out whether session cookies are accepted. Check the settings of your browser and confirm that a cookie for your domain (I guess it's "localhost") with the name PHPSESSID can be found.

Thursday, September 22, 2022

First up: you should never, ever, use md5 to hash passwords. Read this article on why, and then use Go's bcrypt package. You should also parameterise your SQL queries else you are open to catastrophic SQL injection attacks.

Anyway: there are a few problems you need to address here:

  • Your sessions aren't "sticking" is that you're setting the Path as /loginSession - so when a user visits any other path (i.e. /), the session isn't valid for that scope.

You should be setting up a session store on program initialisation and setting the options there:

var store = sessions.NewCookieStore([]byte("something-very-secret"))

func init() {

   store.Options = &sessions.Options{
    Domain:   "localhost",
    Path:     "/",
    MaxAge:   3600 * 8, // 8 hours
    HttpOnly: true,

The reason you might set a more specific path is if logged in users are always within a sub-route like /accounts. In your case, that's not what's happening.

I should add that Chrome's "Resource" tab in the Web Inspector (Resources > Cookies) is incredibly useful for debugging issues like these as you can see the cookie expiry, path and other settings.

  • You're also checking session.Values["email"] == nil, which doesn't work. An empty string in Go is just "", and because session.Values is a map[string]interface{}, you need to type assert the value to a string:


if val, ok := session.Values["email"].(string); ok {
      // if val is a string
      switch val {
             case "":
                 http.Redirect(res, req, "html/login.html", http.StatusFound)
                 http.Redirect(res, req, "html/home.html", http.StatusFound)
    } else {
        // if val is not a string type
        http.Redirect(res, req, "html/login.html", http.StatusFound)

We deal with the "not a string" case so we're explicit about what the program should do if the session is not how we expected (client modified it, or an older version of our program used a different type).

  • You are not checking errors when saving your sessions.

    sessionNew.Save(req, res)

... should be:

    err := sessionNew.Save(req, res)
    if err != nil {
            // handle the error case
  • You should get/validate the session in SessionHandler before serving static files (you are doing it in a very roundabout way, however):

    func SessionHandler(res http.ResponseWriter, req *http.Request) {
        session, err := store.Get(req, "loginSession")
        if err != nil {
            // Handle the error
        if session.Values["email"] == nil {
            http.Redirect(res, req, "html/login.html", http.StatusFound)
        } else {
           http.Redirect(res, req, "html/home.html", http.StatusFound)
        // This shouldn't be here - router isn't scoped in this function! You should set this in your main() and wrap it with a function that checks for a valid session.
Sunday, October 9, 2022

A full format does not just clean the partition table data, it also checks every sector on the disk surface for corrupted ones. This is primarily why it takes so much longer to perform then a quick format. A quick format just rewrites the partition tables.

From a performance standpoint, there is no difference. When the HDD writes a file to the disk, it just finds the next available "free sector", and overwrites whatever is there (regardless of whether or not it is a 0 or a 1). Think of it like this: a quick format just "deletes" all of the files, whereas a full format performs a sector check of the drive surface, and depending on the formatting utility, may fill the drive with zeroes (the default format utilities included with Windows do not zero-fill the drive. Most disk manufacturers provide diagnostic utilities which include the ability to do this.

If the drive is brand new, you should be fine with a quick format. If the drive has corrupted sectors (or even if you think that it does), it would be worth your time to do the full format. If you want to play it safe, ensure that you do at least one full format to the drive. That should reveal all bad sectors, and from then on, you can just do quick formats.

Monday, December 5, 2022
Only authorized users can answer the search term. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :

Browse Other Code Languages