[PHP] Using require instead of redirect architecture
Maybe I'm too old a dog to teach a new trick to. I've got the redirect example discussed a couple days ago working nicely. Back, Refresh, 'wrong username' - all work nicely. But I like the idea of reducing the load on the server, maybe alleviating some redirect pinball. So been trying to use require instead, and all hell has broken loose. Clearly I'm not structuring these pages correctly, but I've run into a conceptual wall of what I should be doing. p1.php: - display form - post to p2.php p2. php - grab and validate input - if good, require p3.php (which says congrats!) - if bad, set error message and require p1.php (which displays error msg and displays form again) Problems: - hitting back on p2.php shows the dreaded The page you are trying to view contains POST... -- OK and Cancel both generated unsatisfactory results - hitting refresh on p2.php runs the validation again, which means the validation code now has to be that much more complicated to trap for a second attempt, blah blah blah. So the architecture needs to look different. Been hitting my head against a wall - I'll be darned if I can figure out what it is. -- RE, Chicago -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Using require instead of redirect architecture
1. p1.php would post to itself. Do data validation. After data validation upon error, include p1.php again with included error messages upon success, redirect to p3.php with congrats. Yeah, I could do this, but it uses a redirect, and like you said, it's gnarly. 2. p1.php would post to p2. perform data validation. upon error, save data into session variable, redirect back to p1.php, display error messages inline upon success, redirect to p3.php, display congrats I've already got this working, per thread of a couple days ago. But it uses a redirect. I personally like the second option. It is cleaner. Each page/script has a single purpose in life. It just makes better sense to my small little mind. I agree as well. But I'm trying to get away from multiple trips to the server for simple page calls, per some pundits on the list. :) So I'm trying to learn a different architecture, and I'm not getting it yet. -- RE, Chicago -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: [PHP-DB] Credit Card Encryption
When it comes to liability, who is liable, the merchant running the system, the develper that created the system, or both? If the develper is included, would that be mitigated in that he created the system to the merchant's specifications? Also, in terms of the developer, would this be covered under errors and omissions insurance, or would they take the position that the developer should have known better and was negligent in creating a non-compliant system leaving the developer on the hook for damages? Unfortunately, I'd argue that he who has the best lawyers wins. -- RE, Chicago -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PRG pattern - how to implement a load page using GET
And I basically completely disagree with the author in the first place, so... Well, that's been clear for a year. :) (P.S. I'll get to the issue of rearchitecting this via require instead of using header() redirects,cough, cough, Richard Lynch, cough, cough :) in a future message. One step at a time...) ... you can probably just ignore this, as it's diametrically opposed to the rules you're following, as I understand them. 'tain't gonna ignore it. Just want to understand the PRG first. Much better to understand something before dismissing it. Simply saying 'it sucks' without understanding it is sorta ignorant. Course, I may end up disagreeing with you, but we won't know that until next week's exciting episode. -- RE, Chicago -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PRG pattern - how to implement a load page using GET
I've been reading up on login mechanisms using redirects, and have a
basic mechanism down.
a1.php:
?php
$site_title='My Site';
if (isset($_SESSION['errmsg_s']))
{$errmsg = 'Warning! '.$_SESSION['errmsg_s'].'!';}
else
{$errmsg = ''; }
if (isset($_SESSION['email_s']))
{ unset($_SESSION['email_s']);}
echo 'h1Welcome to '.$site_title.'/h1br';
echo $errmsg;
?
!-- form goes here and calls a2.php --
a2.php:
?php
$email = $_POST['email'];
if // (test email for goodness against database) {
$_SESSION['email_s'] = $email;
unset($_SESSION['errmsg_s']);
// stuff successful login into database
session_write_close();
header('Location: a3.php');
exit;}
else {
$_SESSION['errmsg_s']=Re-enter your email;
unset($_SESSION['email_s']);
session_write_close();
header('Location: a1.php');
exit;}
?
a3.php:
?php
if (empty($_SESSION['email_s'])) {
session_write_close();
header('Location: a1.php');
exit;}
$email = $_SESSION['email_s'];
echo 'Hello there,'.$email.'. We are glad to have you here.br';
?
OK, looks like this handles refresh (resubmit) and back button issues.
Hitting back when on page 3 empties 'email', so resubmitting does a
brand new login. (If I'm missing something, holler.)
However, the seminal article at
http://www.theserverside.com/tt/articles/article.tss?l=RedirectAfterPost
says:
- Never show pages in response to POST
- Navigate from POST to GET using REDIRECT
- Always load pages using GET
I get the first and the second, and understand how to implement them.
The third, though. Sorry, I'm missing something. I simply don't
understand what they mean or how to do it. Can someone translate my
little a3.php page into 'using GET' instead of just grabbing the
session var again? And why is that necessary?
(P.S. I'll get to the issue of rearchitecting this via require instead
of using header() redirects,cough, cough, Richard Lynch, cough, cough
:) in a future message. One step at a time...)
--
RE, Chicago
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PRG pattern - how to implement a load page using GET
a standard HTTP request is a GET request. I guess I'm just missing some basic definition of terminology. Been writing desktop systems for too long, 'spose. using firefox and one of a number of extensions (firebug springs to mind) you can actually view the request headers that are sent. Firebug shows headers for the c3.php page are: Response Headers: DateSun, 16 Dec 2007 20:48:43 GMT Server Apache/2.2.6 (Fedora) X-Powered-ByPHP/5.1.6 Expires Thu, 19 Nov 1981 08:52:00 GMT Cache-Control no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma no-cache Content-Length 51 Connection close Content-Typetext/html; charset=UTF-8 Request Headers: Hostlocalhost User-Agent Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070812 Remi/2.0.0.6-1.fc6.remi Firefox/2.0.0.6 Accept text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language en-us,en;q=0.5 Accept-Encoding gzip,deflate Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive 300 Connection keep-alive Referer http://localhost/hf/c1.php Cookie PHPSESSID=spave8i7jc7m0cmmvcdaj3msh7 (P.S. I'll get to the issue of rearchitecting this via require instead of using header() redirects,cough, cough, Richard Lynch, cough, cough :) in a future message. One step at a time...) yes - abusing redirects as described is wasteful. and certainly it's the first time I've ever heard the statement 'Never show pages in response to POST' sounds like hubris too me. I've seen the statement in a number of messages in the archives here and in google searches. Probably a case of Read Once, Repeat Often. I took it with a grain of salt. They are java guys over there, after all. :) OK, now onto ridding the world of these redirects() -- RE, Chicago -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] how to handle inserting special characters into a mysql field
On Saturday 15 December 2007 18:59:12 Richard Lynch wrote: On Fri, December 14, 2007 11:03 am, Adam Williams wrote: $query = sprintf(SELECT * FROM users WHERE user='%s' AND password='%s', mysql_real_escape_string($user), mysql_real_escape_string($password)); and I understand it uses the %s because of sprintf(), to indicate the data is a string. However, thats not syntax I'm used to seeing. If I rewrite the code to the following below, will it return the same results or error when queried? $user = mysql_real_escape_string($user); $password = mysql_real_escape_string($password) $query = SELECT * FROM users WHERE user='$user' AND password='$password'; Yes, you will get the same result. You could have run both sets of code to try it faster than I typed this answer. If the OP was _thinking_ the same thing I was, the question was actually, What's the difference and why use one vs the other? Yeah, I could run both and see the same result (actually, I did), but don't understand the _wisdom_ of one choice over the other. -- RE, Chicago -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Session call not creating file in session_save_path - perms? (newbie)
OK, I've read every message on the list for the last year that contains
'sessions'. I've read through (bleary eyed, admittedly)
http://us2.php.net/session. And I swear, honest, that I had this working on
another box (which is no longer available to me.) I've checked phpinfo -
session support is on, session.use_cookie is On. PHP 5.1.6 or thereabouts.
?php session_start();
session_save_path('/home/rob//Sites/zphpsessions');
echo 'sessionid:'.session_id().':br';
echo 'save path:'.session_save_path().':br';
$ip = ' '.$_SERVER['REMOTE_ADDR'];
echo '$ip is:'.$ip.':br';
$_SESSION['ipx']=$ip;
echo 'ipx (session) is:'.$_SESSION['ipx'].':br';
if (!isset($_SESSION['ipx'])) echo 'whoa nelly';
echo 'This is the main page';
?
Output looks like this:
sessionid:8klvud4o186lme7n6v84lhfjl2:
save path:/home/rob/Sites/zphpsessions:
$ip is: 127.0.0.1:
ipx (session) is: 127.0.0.1:
This is the main page
No data is being dumped into /home/rob/Sites/zphpsessions. The best I can
guess is permissions. If I change save_path to /tmp, no difference - still
nothing being written there. I bet I'm doing something ignorant about apache
users or something, huh?
--
RE, Chicago
Re: [PHP] Session call not creating file in session_save_path - perms? (newbie)
Aw crap. :) (session_save_path BEFORE session_start.) Works fine now... now to clean the egg off face. Thx, On Dec 12, 2007 11:31 PM, Casey [EMAIL PROTECTED] wrote: Read manual please. http://us.php.net/session_save_path -- RE, Chicago
