Re: Help Please!
| From: | Doug Semig | Date: | Fri, 03 Nov 2000 05:43:32 +0000 |
| Subject: | Re: Help Please! | ||
| References: | 1 | Groups: | php.db |
| Request: | Send a blank email to php-db+get-4170@lists.php.net to get a copy of this message | ||
Hi Jay--
I confess that I completely do not understand why they have to pass
anything more than just the SID to the visitor's browser. What's the point
of using sessions if you're going to URL encode everything and pass it all
back and forth?
But perhaps the people above you should explain themselves to you instead
of the other way 'round? You didn't indicate the problem they are trying
to solve with their solution. Although I cannot fathom a reason to pass
anything other than a SID when using PHP4 sessions, perhaps there is a reason?
There's technically nothing wrong with encrypting and decrypting data with
every page view if that is what's required. After all, that's what
SSL/HTTPS does all the time! Just size your server (or servers) accordingly.
But only knowing half the story, it is only based on principle that I can
condemn the practice of sending/receiving data that might be more properly
stored and restored by PHP4's session handling features.
If you or they are worried about Oracle's performance, just store the
session data somewhere else. Flat files are the default, but you can
certainly use ndbm, MySQL, PostgreSQL, Interbase, a different Oracle
server, or just about anything else you can dream up.
Doug
At 05:26 PM 11/2/00 -0600, Paulson, Joseph V. \"Jay\" wrote:
>Hello everyone!
>I need some help convincing the people above me on a certain issue because
>I'm lead to believe that they are going about it in the wrong manner. Here
>is the issue, we are using PHP4 session handling for a huge website which
>has 500,000 customers. We are expecting about 30% of these customers to
>actually do business through this website and of course have the base
>customers grow as well.
>
>At any rate, what they are wanting to do is put the primary keys for users
>accounts encrypted using the Blowfish algorithm with two modifications on it
>and then putting the encrypted information in the url along with the session
>id. My big complaint is that you are going to have to encrypt and decrypt
>the user's information on every page of the application, in turn using a ton
>of cpu power. The only reason why they are going to be using sessions is to
>keep each user unique.
>
>We run a huge Oracle database and I have suggested to put all the session
>information into that database and avoid using the encryption / decryption.
>However, they do not want to put any more hits on the database than possible
>because at some points of the day it becomes a little sluggish. Since I'm
>not a dba is it safe to assume that making the session handling via oracle
>wouldn't bog it down anymore than it already is?
>
>I'm just trying to avoid having to write this encryption and decryption code
>that I know is going to slow the site down when we could just put the
>information into oracle and it would be safe and secure. Am I correct in
>assuming all of this? From what I have read I feel that this is a safe bet
>and is used all over the web.
>
>Anyway, any comments/seggestions on this matter is more than welcome!
>
>Thanks,
>Jay Paulson