james

Hey everyone! I'm very new to PHP, and had a somewhat general question
(f****ve me if it's too broad in scope.) Basically, I'd like to be able
to have a single PHP application that remembers its state as users click
on links. When the user clicks on a link, though, the user unavoidably
re-requests the URL from the web server, which forces the PHP
application to reload. I'm therefore uncertain as to how I should keep
the program in a state in which it remembers things like login
information when the users have to click on links in order to navigate
the application.

This is especially an issue for me when it comes to maintaining things
like persistent connections to SQL servers.

Thanks!

James

tedd.sperling

James:

There are several ways to do what you want. You can store your variables in:

1. A $_SESSION variable;

2. A $_COOKIE variable;

3. A $_POST variable;

4. A $_GET variable;

5. A field in MySQL dB;

However, all (1-5) of those via php will require a page refresh to
send them on to the next page and for the next page to read them in
again. IOW, to read back in the variables in whatever form.

6. If you use javascript, then you can use your variables
(client-side) and then send them to php when you're ready to use them
server-side -- of course that's after validation and it again
requires a page refresh.

7. You can combine ajax (javascript with a "behind the scenes"
communication with the server) and php to produce a page that doesn't
refresh, but the page keeps it's state.

However, with (6-7) your web page will require javascript to be
turned ON by the user and a significant number of users (~10%) don't
have js turned ON.

So there are several ways, but each has it's trade-offs.

Cheers,

tedd

PS: Gang -- if I have missed one, please jump in and correct me.
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com

eric.butera

Well php itself is stateless, aka "share nothing." On each request
everything is always going to be built from the ground up unless you
really step in the way with other technologies such as an opcode cache
and memcached.

You can use the session extension to remember state between requests.
When someone posts a login form and it is correct, just throw the user
id into the session. Then always check for a valid user id variable
in the session when you need authorization.

http://php.net/manual/en/session.examples.php

As for your database concern, most (if not all) of the db extensions
offer some sort of persistent connection pooling capability. For
example ext/mysql offers mysql_pconnect. With PDO you can do this:

$dbh = new PDO('mysql:host=localhost;dbname=test', $user, $pass, array(
PDO::ATTR_PERSISTENT => true
));

james

Hey tedd, thanks for the response!


After googling briefly on the subject of sessions, it looks like this is
probably the way I'd want to go. I like this idea, because I can
modularize the code and call different php scripts for different
actions. I could have each script check for the proper session
variables, and if they don't exist, redirect the user to the login page.

I'm assuming that a session will last as long as the browser is open (or
until it's ********ly destroyed), correct? Are there any security
issues I should be aware of? Since there's a login, I'd be serving this
over SSL, and the user's password would be stored as an SHA1 hash in the
MySQL db.

James
--
My blog: http://www.crazydrclaw.com/
My homepage: http://james.colannino.org/

"When you do the common things in life in an uncommon way, you will
command the attention of the world." --George Washington Carver

larry

1) PHP applications are built on the concept of shared-nothing. Every page
request is, and should be, entirely independent of another. That is by
design. It's weird if you're used to stateful programming (desktop, JSP,
etc.), but it is actually very powerful.

2) If you really need to persist something, keep it small and use sessions[1].
They exist for that purpose.

3) 95% of the time, persistent connections to SQL servers are more trouble
than they're worth. If you're using MySQL or SQLite in particular, the
connection cost is tiny. In practice it's better to just let the connection
die at the end of the request and re-open it at the start of the next
request. The web has been optimized over the past decade for that usage
pattern.

[1] http://www.php.net/sessions


--
Larry Garfield AIM: LOLG42
larry@garfieldtech.com ICQ: 6817012

"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it." -- Thomas
Jefferson

eric.butera

Sessions last as long as they are configured for. You can see these
values in the php.ini
http://php.net/manual/en/session.configuration.php

Security concerns:
http://talks.php.net/show/phpworks2004-php-session-security

tedd.sperling

James:

Not meaning to be short, but all questions about sessions can be
better answered via the manuals.

As for security, it's better if you read about it -- it longer and
more complicated than what an email exchange would allow. I recommend
purchasing Essential PHP Security (2005 O'Reilly)

http://shiflett.org/

In my estimation, that's essential.

Storing the user's password as a MD5 hash on MySQL is what I do -- it
works for me.

Cheers,

tedd

--
-------
http://sperling.com http://ancientstones.com http://earthstones.com

news

Ive starting using Pear cache_lite(). Works great for maintaining stuff between page refreshes. You
can set the retention time to anything reasonable.