Jump to content

Scrapping Sessions for mySQL


ChenXiu
 Share

Recommended Posts

Posted (edited)

After MONTHS of wrestling with "Sessions," battling ENDLESS "undefined index," "undefined this or that," "this array is not a string you idiot" errors, I think my website finally works.

NOW I WANT TO SCRAP IT ALL!

While fighting Sessions a few weeks ago, one of the best Admins here tossed out an idea, "...or you could use mySQL."

I thought the suggestion was ridiculous ("just answer my damn question don't give me stupid alternatives")... but now the more I think about it:

1.) Sessions are a pain.
2.) Sessions are really glorified cookies
   a.) Nobody really likes cookies
   b.) Time is wasted contemplating the 'GDPR compliance' loophole (I don't want a dumb banner on my site)
3.) Sessions DO add a drag/overhead that IS noticeable, albeit barely.
4.) MANY people proudly have "cookies disabled" on their browser

Conversely, mySQL is
1.) Ridiculously fast
2.) Appears to me Virtually BULLETPROOF from a "server storing server-generated data" standpoint.
3.) If you love annoying banners, you can put one up that says "THIS SITE DOES NOT USE COOKIES!"

BUT.... There are 2 problems I need to overcome:
Problem 1.) How to "maintain state" i.e. follow visitor through the site?
Maybe generate a unique ID like this? $uniqueID = openssl_random_pseudo_bytes(openssl_cipher_iv_length('aes-256-cbc'));
Problem 2.) My product page expands as visitor continues POSTs more products to it...... How do I "maintain state" if visitor tries to add an additional product via a $_GET request from a referral page?

Example:

Product Page:
Bicycle: $25.00
// visitor now posts a Horse:
Product Page now says:
Bicycle: $25.00
Horse: $100.00
// visitor now posts a Buggy:
Product Page now says:
Bicycle: $25.00
Horse: $100.00
Buggy: $10.00
// visitor now adds a Donkey, via Referral Page:
Product Page now says:
Donkey: $25.00
(Notice how all $_POST data just got lost?)

Hmmm.......

Any thoughts will be appreciated (maybe not appreciated right away, but eventually 😀 )


 

Edited by ChenXiu
Link to comment
Share on other sites

8 hours ago, ChenXiu said:

1.) Sessions are a pain.

Sessions are easy unless you have a terribly architected website.

Quote

2.) Sessions are really glorified cookies

Kinda.

Quote

   a.) Nobody really likes cookies

Nobody likes tracking cookies. People don't know it but they do like cookies.

Quote

   b.) Time is wasted contemplating the 'GDPR compliance' loophole (I don't want a dumb banner on my site)

Enjoy your lawsuit.

Quote

3.) Sessions DO add a drag/overhead that IS noticeable, albeit barely.

The only way a session should have noticeable overhead on your site is if your webserver is a potato.

Quote

4.) MANY people proudly have "cookies disabled" on their browser

Not as many as you think. Even so, these people do like using the internet, which requires cookies to function, so they're necessarily used to adding exceptions in their browsers.

Quote

Conversely, mySQL is
1.) Ridiculously fast

For relatively small databases at relatively low activity levels, yes. It doesn't do as well at high traffic, high concurrency loads as some other systems.

Quote

2.) Appears to me Virtually BULLETPROOF from a "server storing server-generated data" standpoint.

If you thought sessions were hard then databases are going to be harder.

Quote

3.) If you love annoying banners, you can put one up that says "THIS SITE DOES NOT USE COOKIES!"

*Tracking cookies.

If you want to disallow all cookies then there are a lot of completely normal things you're going to have to make do without. Such as:

Quote

BUT.... There are 2 problems I need to overcome:
Problem 1.) How to "maintain state" i.e. follow visitor through the site?
Maybe generate a unique ID like this? $uniqueID = openssl_random_pseudo_bytes(openssl_cipher_iv_length('aes-256-cbc'));

You can't. Not without cookies. Not safely.

edit: Actually no, it is possible, but it creates a terrible user experience: the user can't use their back and forward history buttons.

Link to comment
Share on other sites

Posted (edited)
56 minutes ago, requinix said:

Sessions are easy unless you have a terribly architected website.

No, I'm just dumb. I have no formal training in PHP, everything I learned is just from goofing around with it.  My website is basically one page, not a whole lot of 'architecture' 😀

56 minutes ago, requinix said:

Enjoy your lawsuit.

I don't know....  Did you read the "it is not required to obtain consent for these cookies" section of the GDPR (https://gdpr.eu/cookies/) ???

56 minutes ago, requinix said:

is if your webserver is a potato.

I think you're right. Maybe more like a Yam 😀

56 minutes ago, requinix said:

It doesn't do as well at high traffic

I didn't think of that! Thank you for pointing that out. In fact, I remember the Boss of my shared hosting account scolding me for so many mySQL queries (must have overloaded his dialup connection).

56 minutes ago, requinix said:

the user can't use their back and forward history buttons.

My experience is the opposite. When I implemented Sessions, the ability to go backwards and forwards was lost! In fact, I had to implement "ini_set('session.cache_limiter','public'); session_cache_limiter(false);" so that visitors COULD "go back / go forward." But something is telling me this is the wrong thing to do. What do you think?

 

Edited by ChenXiu
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.