|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
php-general-digest-help
lists.php.net
Date: Tue Mar 18 2008 - 17:40:07 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
php-general Digest 18 Mar 2008 22:40:07 -0000 Issue 5355
Topics (messages 271702 through 271752):
Re: help on using 'request_uri' to make a front-end site
271702 by: Donn
271703 by: Richard Heyes
271712 by: Donn
passing variables values using POST
271704 by: Sudhakar
271706 by: Stut
271707 by: viraj
271708 by: Jason Pruim
General use of rewrite / redirect
271705 by: Aschwin Wesselius
271711 by: Per Jessen
271714 by: Aschwin Wesselius
271715 by: Thijs Lensselink
271717 by: Børge Holen
271718 by: jeffry s
271719 by: Aschwin Wesselius
271720 by: Per Jessen
271721 by: Per Jessen
271722 by: Per Jessen
271727 by: Per Jessen
271730 by: Aschwin Wesselius
271731 by: Jason Pruim
271732 by: Jason Pruim
271733 by: Stut
271734 by: Stut
271735 by: Thijs Lensselink
271737 by: Per Jessen
271738 by: Stut
question about direct access to url
271709 by: Sudhakar
271710 by: Stut
271713 by: Donn
Re: problem with this regex to remove img tag...
271716 by: David Giragosian
271729 by: Daniel Brown
PHP 5 file_get_contents() problems
271723 by: Chris
271724 by: Greg Bowser
271725 by: Thijs Lensselink
271726 by: Greg Bowser
271728 by: Thijs Lensselink
Re: __halt_compiler()
271736 by: Philip Thompson
Closures
271739 by: Ray Hauge
Re: Is this the best way?
271740 by: TG
271741 by: Jochem Maas
271742 by: Jason Pruim
271743 by: Jason Pruim
Problems posting xml file with curl and php
271744 by: michaelh613
271745 by: Nathan Nobbe
271746 by: michaelh613
271747 by: Nathan Nobbe
271748 by: michaelh613
271750 by: Nathan Nobbe
SOAP Server in PHP4
271749 by: Eric Gorr
271751 by: Nathan Nobbe
Some Good News
271752 by: Daniel Brown
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscribelists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscribelists.php.net
To post to the list, e-mail:
php-generallists.php.net
----------------------------------------------------------------------
attached mail follows:
On Tuesday, 18 March 2008 12:02:14 Richard Heyes wrote:
> You can use $_SERVER['PHP_SELF'] which will give you the path to the
> script or $_SERVER['REQUEST_URI'] (you will probably have to remove the
> query string with this), along with either dirname().
The problem is that the URL does not stay constant, it keeps growing. For
example after clicking between home and use1 a few times I see these values,
note how index.php repeats:
'REQUEST_URI':/~donn/template-dev/routertest/index.php/index.php/home
dirname('REQUEST_URI'):/~donn/template-dev/routertest/index.php/index.php
I suppose some kind of htaccess voodoo could help here, but I am in no shape
to grok those murky waters.
A link <a href="index.php/use1"> causes 'index.php/use1' to be appended to the
full url [http://localhost/~donn/template-dev/routertest/] and at first, it's
fine but after a few clicks, it keeps appending. Amazingly things still work,
but the URL is out of control!
All I can think to use to enforce correct link behaviour is to employ absolute
urls.
Thanks for the feedback.
\d
attached mail follows:
> A link <a href="index.php/use1"> causes 'index.php/use1' to be appended to the
> full url [http://localhost/~donn/template-dev/routertest/] and at first, it's
> fine but after a few clicks, it keeps appending. Amazingly things still work,
> but the URL is out of control!
Links that don't start with a / are taken to be relative to the current
documents path. You (probably) want this:
<a href="/~donn/blah/index.php/use1">
The forward slash at the start causes your browser to ignore whatever
your current path is, albeit remain on the current domain.
--
Richard Heyes
Employ me:
http://www.phpguru.org/cv
attached mail follows:
Richard Heyes wrote:
> The forward slash at the start causes your browser to ignore whatever
> your current path is, albeit remain on the current domain.
Okay, I think I am getting confused by this ~donn/ virtual path thing. I
will try your suggestion it looks good.
Thanks.
\d
attached mail follows:
i am presently passing the value of a variable to a php file using GET
after data has been inserted to the database.
ex=
$firstname = $_POST["firstname"];
if(!$sqlconnection)
{
echo "error message";
}
else
{
header("Location: thankyou.php?firstnameis=$firstname");
}
how can i send the value of $firstname using POST instead of GET as
the value is presently appearing in the address bar. ideally i would
like using POST.
NOTE = please suggest techniques that does NOT involve javascript in
order to pass $firstname using POST method, as i have done the entire
validations using php and i have assumed that user has javascript
turned off.
please advice.
thanks.
attached mail follows:
On 18 Mar 2008, at 10:43, Sudhakar wrote:
> i am presently passing the value of a variable to a php file using GET
> after data has been inserted to the database.
>
> ex=
>
> $firstname = $_POST["firstname"];
>
> if(!$sqlconnection)
> {
> echo "error message";
> }
> else
> {
> header("Location: thankyou.php?firstnameis=$firstname");
> }
>
> how can i send the value of $firstname using POST instead of GET as
> the value is presently appearing in the address bar. ideally i would
> like using POST.
>
> NOTE = please suggest techniques that does NOT involve javascript in
> order to pass $firstname using POST method, as i have done the entire
> validations using php and i have assumed that user has javascript
> turned off.
In that case it can't be done. You cannot trigger a post on the client-
side without using Javascript.
Why do you need to redirect? Why can't you display the thankyou.php
page inline rather than bouncing off the client?
-Stut
--
http://stut.net/
attached mail follows:
On Tue, Mar 18, 2008 at 12:45 PM, Stut <stuttlegmail.com> wrote:
> On 18 Mar 2008, at 10:43, Sudhakar wrote:
> > i am presently passing the value of a variable to a php file using GET
> > after data has been inserted to the database.
>
> Why do you need to redirect? Why can't you display the thankyou.php
> page inline rather than bouncing off the client?
or you can register the firstname into a session variable and use it
on the landing page.
but what stut suggests is the best.
~viraj
>
> -Stut
>
> --
> http://stut.net/
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
attached mail follows:
On Mar 18, 2008, at 6:43 AM, Sudhakar wrote:
> i am presently passing the value of a variable to a php file using GET
> after data has been inserted to the database.
>
> ex=
>
> $firstname = $_POST["firstname"];
>
> if(!$sqlconnection)
> {
> echo "error message";
> }
> else
> {
> header("Location: thankyou.php?firstnameis=$firstname");
> }
>
> how can i send the value of $firstname using POST instead of GET as
> the value is presently appearing in the address bar. ideally i would
> like using POST.
>
> NOTE = please suggest techniques that does NOT involve javascript in
> order to pass $firstname using POST method, as i have done the entire
> validations using php and i have assumed that user has javascript
> turned off.
by the looks of it... You already have it setup right... basically you
would you something like this:
FORM:
<form method="post" action="mysuperphppage.php">
<input type="text" name="txtfirstname">
<input type="submit">
</form>
mysuperphppage.php:
<?PHP
$firstname = $_POST['txtfirstname'];
echo <<<HTML
Thank you {$firstname}, You're the best!
HTML;
?>
Of course, all untested, but it should get you the basics...
--
Jason Pruim
Raoset Inc.
Technology Manager
MQC Specialist
3251 132nd ave
Holland, MI, 49424-9337
www.raoset.com
japruimraoset.com
attached mail follows:
Hi,
In too many projects / scripts / examples, I see rewrites or redirects
being done like (pseudocode):
if (good) {
do something
} else {
header (location: http://otherpage)
exit
}
Is this a best practice? What arguments are there to use this kind of
mechanism?
I've seen form processing being done, when finished it gets a header
redirect to a 'succes' page.
I've seen URL's with wrong or insufficient parameters being redirected
this way.
I've seen too many horrible things that actually belongs into a black
book of webscripting.
What is your opinion about (ab)using rewrites / redirects? Do you use it
quick and dirty, or is it some elegant way of controlling flow?
Thanks.
--
Aschwin Wesselius
/'What you would like to be done to you, do that to the other....'/
attached mail follows:
Aschwin Wesselius wrote:
> I've seen form processing being done, when finished it gets a header
> redirect to a 'succes' page.
Yes, that's a very typical setup. When the form is processed, you send
a 303 redirect to the "Thank you" page. That way, if the user hits
the "back" arrow, he's taken back to the form URL, not the post URL.
(which would then warn him about re-submitting etc.)
> What is your opinion about (ab)using rewrites / redirects? Do you use
> it quick and dirty, or is it some elegant way of controlling flow?
I think there are plenty of perfectly valid reasons for using a
redirect, whether dynamically from php or via an apache config.
And undoubtedly there equally many poor reason for using redirect and/or
rewrite. (they're very different things, by the way).
/Per Jessen, Zürich
attached mail follows:
Per Jessen wrote:
> Yes, that's a very typical setup. When the form is processed, you send
> a 303 redirect to the "Thank you" page. That way, if the user hits
> the "back" arrow, he's taken back to the form URL, not the post URL.
> (which would then warn him about re-submitting etc.)
>
Ok, fine. But why do a real redirect when a header with 303 could be
sufficient? If you model good enough, there would not be a need for
header(location) redirects. Or am I wrong?
>> What is your opinion about (ab)using rewrites / redirects? Do you use
>> it quick and dirty, or is it some elegant way of controlling flow?
>>
> I think there are plenty of perfectly valid reasons for using a
> redirect, whether dynamically from php or via an apache config.
> And undoubtedly there equally many poor reason for using redirect and/or
> rewrite. (they're very different things, by the way).
I know they're different things. I only want to start a discussion so
people do understand other techniques instead of just using whatever
'works' as a solution to their problem with flow. Redirects do solve
some issues, but they should be avoided whenever possible.
header(location) mechanisms do come with a very huge disadvantage if you
don't use them with caution. Requests are reinitialised, libraries
loaded (again), DB connections setup/checked again, session lookups are
being done, log write for another request etc. That's quite an impact
for just not knowing what to do with flow. So, if you know what you want
to handle (control) and what you want the user to see (view), one should
be able to model it without the use of redirects unless it really is needed.
Or is it OK, to redirect and 'simplify' the flow?
--
Aschwin Wesselius
/'What you would like to be done to you, do that to the other....'/
attached mail follows:
Quoting Aschwin Wesselius <aschwinilluminated.nl>:
> Per Jessen wrote:
>> Yes, that's a very typical setup. When the form is processed, you send
>> a 303 redirect to the "Thank you" page. That way, if the user hits
>> the "back" arrow, he's taken back to the form URL, not the post URL.
>> (which would then warn him about re-submitting etc.)
>>
> Ok, fine. But why do a real redirect when a header with 303 could be
> sufficient? If you model good enough, there would not be a need for
> header(location) redirects. Or am I wrong?
>>> What is your opinion about (ab)using rewrites / redirects? Do you use
>>> it quick and dirty, or is it some elegant way of controlling flow?
>>>
I think there are valid reasons for using a header(location) redirect.
As Per already pointed out. I don't see what using header() has to do
with a good design. Sometimes you just want to do a redirect 303 or
not :)
>> I think there are plenty of perfectly valid reasons for using a
>> redirect, whether dynamically from php or via an apache config.
>> And undoubtedly there equally many poor reason for using redirect
>> and/or
>> rewrite. (they're very different things, by the way).
> I know they're different things. I only want to start a discussion so
> people do understand other techniques instead of just using whatever
> 'works' as a solution to their problem with flow. Redirects do solve
> some issues, but they should be avoided whenever possible.
>
> header(location) mechanisms do come with a very huge disadvantage if
> you don't use them with caution. Requests are reinitialised, libraries
> loaded (again), DB connections setup/checked again, session lookups are
> being done, log write for another request etc. That's quite an impact
> for just not knowing what to do with flow. So, if you know what you
> want to handle (control) and what you want the user to see (view), one
> should be able to model it without the use of redirects unless it
> really is needed.
Not much different from a normal page load.
>
> Or is it OK, to redirect and 'simplify' the flow?
I think it's ok to use. Also think about the fact that not all PHP
applications are giant OO monsters. There's some simple scripts out
there also. For wich header would be sufficient.
> --
>
> Aschwin Wesselius
>
> /'What you would like to be done to you, do that to the other....'/
attached mail follows:
On Tuesday 18 March 2008 14:22:26 Aschwin Wesselius wrote:
> Per Jessen wrote:
> > Yes, that's a very typical setup. When the form is processed, you send
> > a 303 redirect to the "Thank you" page. That way, if the user hits
> > the "back" arrow, he's taken back to the form URL, not the post URL.
> > (which would then warn him about re-submitting etc.)
>
> Ok, fine. But why do a real redirect when a header with 303 could be
> sufficient? If you model good enough, there would not be a need for
> header(location) redirects. Or am I wrong?
>
> >> What is your opinion about (ab)using rewrites / redirects? Do you use
> >> it quick and dirty, or is it some elegant way of controlling flow?
> >
> > I think there are plenty of perfectly valid reasons for using a
> > redirect, whether dynamically from php or via an apache config.
> > And undoubtedly there equally many poor reason for using redirect and/or
> > rewrite. (they're very different things, by the way).
>
> I know they're different things. I only want to start a discussion so
> people do understand other techniques instead of just using whatever
> 'works' as a solution to their problem with flow. Redirects do solve
> some issues, but they should be avoided whenever possible.
>
> header(location) mechanisms do come with a very huge disadvantage if you
> don't use them with caution. Requests are reinitialised, libraries
> loaded (again), DB connections setup/checked again, session lookups are
> being done, log write for another request etc. That's quite an impact
> for just not knowing what to do with flow. So, if you know what you want
> to handle (control) and what you want the user to see (view), one should
> be able to model it without the use of redirects unless it really is
> needed.
>
> Or is it OK, to redirect and 'simplify' the flow?
Are you asking or informing? The way of; I know it all, how do I do it? is
confusing. All you do is stating the obvious either way, while it all depends
on the task at hand. You may want to reconnect to a different db, cleaning
out variables and posts? dunno.
Probably you want the least possible transfer over the network since that is
more costly than a new computer to a cluster. But with 10.000 users you have
to do the math yourself, cuz heavy db tasks vs a small increase in traffic...
--
---
Børge Holen
http://www.arivene.net
attached mail follows:
On Tue, Mar 18, 2008 at 9:22 PM, Aschwin Wesselius <aschwinilluminated.nl>
wrote:
> Per Jessen wrote:
> > Yes, that's a very typical setup. When the form is processed, you send
> > a 303 redirect to the "Thank you" page. That way, if the user hits
> > the "back" arrow, he's taken back to the form URL, not the post URL.
> > (which would then warn him about re-submitting etc.)
> >
> Ok, fine. But why do a real redirect when a header with 303 could be
> sufficient? If you model good enough, there would not be a need for
> header(location) redirects. Or am I wrong?
> >> What is your opinion about (ab)using rewrites / redirects? Do you use
> >> it quick and dirty, or is it some elegant way of controlling flow?
> >>
> > I think there are plenty of perfectly valid reasons for using a
> > redirect, whether dynamically from php or via an apache config.
> > And undoubtedly there equally many poor reason for using redirect and/or
> > rewrite. (they're very different things, by the way).
> I know they're different things. I only want to start a discussion so
> people do understand other techniques instead of just using whatever
> 'works' as a solution to their problem with flow. Redirects do solve
> some issues, but they should be avoided whenever possible.
>
> header(location) mechanisms do come with a very huge disadvantage if you
> don't use them with caution. Requests are reinitialised, libraries
> loaded (again), DB connections setup/checked again, session lookups are
> being done, log write for another request etc. That's quite an impact
> for just not knowing what to do with flow. So, if you know what you want
> to handle (control) and what you want the user to see (view), one should
> be able to model it without the use of redirects unless it really is
> needed.
>
> Or is it OK, to redirect and 'simplify' the flow?
> --
>
> Aschwin Wesselius
>
> /'What you would like to be done to you, do that to the other....'/
>
>
i am sorry.. but i don't get what u really want to say. honestly, i don't
see any other way
(better alternative) to avoid people to simply refresh the browser to submit
the form
many time.
>Requests are reinitialised, libraries
>loaded (again), DB connections setup/checked again, session lookups are
>being done, log write for another request etc.
i don't see anything wrong with this since that is the way it is. whether
you redirect or
not, the script will do DB connection, session lookup anyway. i simply
called exit;
to stop execution after the header redirect..
sorry.. if i misunderstand your point. but that is just my opinion..
attached mail follows:
jeffry s wrote:
>> Requests are reinitialised, libraries
>> loaded (again), DB connections setup/checked again, session lookups are
>> being done, log write for another request etc.
>>
>
> i don't see anything wrong with this since that is the way it is. whether
> you redirect or
> not, the script will do DB connection, session lookup anyway. i simply
> called exit;
> to stop execution after the header redirect..
>
> sorry.. if i misunderstand your point. but that is just my opinion..
Ok, let me point it out with an example:
include(this);
include(that);
connect(db);
session check
That is what normally could exist on a script for every page hit.
If you have a page that only does this:
if (GET || POST) {
process form variables
header (location: thankyou)
exit
}
else {
whatever
}
On the thankyou:
echo 'thank you'
What happens is that just for submitting a form (or any process on any
page), most cases all kind of libraries are included, db connection is
made, sessions are checked etc. Besides the effect on PHP, the webserver
does his job too, writing to logs, creating threads etc. Conclusion is
'load per page'.
So what happens in short looks like this:
- do heavy stuff
- process page
- redirect
- do heavy stuff
- show thank you
Why not:
- do heavy stuff
- process page
- show thank you
That is my question. How do you people think about the trade-off of
performance against the ease of just redirecting to another URL just to
be sure a user get's to the right destination?
--
Aschwin Wesselius
/'What you would like to be done to you, do that to the other....'/
attached mail follows:
Aschwin Wesselius wrote:
> Per Jessen wrote:
>> Yes, that's a very typical setup. When the form is processed, you
>> send a 303 redirect to the "Thank you" page. That way, if the user
>> hits the "back" arrow, he's taken back to the form URL, not the post
>> URL. (which would then warn him about re-submitting etc.)
>>
> Ok, fine. But why do a real redirect when a header with 303 could be
> sufficient? If you model good enough, there would not be a need for
> header(location) redirects. Or am I wrong?
What's the difference between a "real redirect" and a header with a 303?
>> I think there are plenty of perfectly valid reasons for using a
>> redirect, whether dynamically from php or via an apache config.
>> And undoubtedly there equally many poor reason for using redirect
>> and/or rewrite. (they're very different things, by the way).
> I know they're different things. I only want to start a discussion so
> people do understand other techniques instead of just using whatever
> 'works' as a solution to their problem with flow. Redirects do solve
> some issues, but they should be avoided whenever possible.
But redirect and rewrite are not solutions to the same "problem" - a
rewrite is altering the URL internally, a redirect happens externally.
> header(location) mechanisms do come with a very huge disadvantage if
> you don't use them with caution. Requests are reinitialised, libraries
> loaded (again), DB connections setup/checked again, session lookups
> are being done, log write for another request etc. That's quite an
> impact for just not knowing what to do with flow.
I'm having difficulties following you - a plain 303 redirect to a "Thank
you" page shouldn't cause all of that. It's an HTTP reply with the 303
and the new URL, followed by a single URL request from the browser.
/Per Jessen, Zürich
attached mail follows:
Aschwin Wesselius wrote:
> Ok, let me point it out with an example:
>
> include(this);
> include(that);
> connect(db);
> session check
>
> That is what normally could exist on a script for every page hit.
Yep, that looks common enough.
> If you have a page that only does this:
>
> if (GET || POST) {
> process form variables
> header (location: thankyou)
> exit
> }
> else {
> whatever
> }
>
> On the thankyou:
>
> echo 'thank you'
>
> What happens is that just for submitting a form (or any process on any
> page), most cases all kind of libraries are included, db connection is
> made, sessions are checked etc. Besides the effect on PHP, the
> webserver does his job too, writing to logs, creating threads etc.
> Conclusion is 'load per page'.
Well, only if you write it like that. The typical "Thank you" page does
not include all of that stuff. It's pretty much static with some
(cached) graphics, a "Thank you" and a link back to the main page (or
whereever).
> That is my question. How do you people think about the trade-off of
> performance against the ease of just redirecting to another URL just
> to be sure a user get's to the right destination?
My typical setup for a form-page probably looks like this:
if ( $_POST )
{
// do POST processing
header(303 thankyou.html).
exit
}
// regular page starts here
// process GET (if any)
// database stuff
// display page.
/Per Jessen, Zürich
attached mail follows:
Per Jessen wrote:
> My typical setup for a form-page probably looks like this:
>
> if ( $_POST )
> {
> // do POST processing
> header(303 thankyou.html).
> exit
> }
If I wanted the user back on the same form page, but still with a "thank
you" message, I'd still do a 303, but use $_SESSION to indicate that
the user needs a "thank you" message displayed.
/Per Jessen, Zürich
attached mail follows:
Aschwin Wesselius wrote:
> Per Jessen wrote:
>>
>> I'm having difficulties following you - a plain 303 redirect to a "Thank
>> you" page shouldn't cause all of that. It's an HTTP reply with the 303
>> and the new URL, followed by a single URL request from the browser.
>>
> OK. I think I know how other people (like you) think about just
> requesting URL's one after another. If that's not such a performance
> issue for you, fine.
It's not really - serving URLs one after another is what apache is good
at :-)
> A plain 303 redirect mostly isn't just a HTML file, it's another script
> (or the same script with another action falling through a switch
> statement, whatever).
I disagree - unless the 303 directs back to a new form-entry, the
redirect URL is almost always a plain static page. Well, in my designs
anyway.
> Point is: why hitting you webserver with multiple requests per user,
> just after submitting a form or whatever caused the redirect? If you
> have 2 users per day, that won't hurt. But if you have 30.000 concurrent
> users a minute, that could be 60.000 requests (besides all the images,
> stylesheets, javascripts that are being re-requested).
Of which a lot will be cached. But I get your point.
The main question is - what is the alternative to the 303? Sometimes I
use a method where I set a messages in $_SESSION which will then be
displayed on the next page, but I usually only use that in closed
(=non-public) web-apps. Even then I still issue the 303 - I don't see
how you can get around that.
Wrt performance - the old adage of "buy a bigger box" is becoming more
and more applicable every day. It's not always one I agree with, but
sometimes performance problems _are_ best solved by a bigger box.
> Or am I talking nonsense?
You seem to be stuck on the possible performance issues in the
superfluous serving and processing of a "Thank you" page. Granted, if
your thankyou.html includes all sort of superfluous processing, you've
got a problem, but you solve that by getting rid of all that superfluous
code (in the 303 page).
/Per Jessen
attached mail follows:
Per Jessen wrote:
>
>> header(location) mechanisms do come with a very huge disadvantage if
>> you don't use them with caution. Requests are reinitialised, libraries
>> loaded (again), DB connections setup/checked again, session lookups
>> are being done, log write for another request etc. That's quite an
>> impact for just not knowing what to do with flow.
>>
>
> I'm having difficulties following you - a plain 303 redirect to a "Thank
> you" page shouldn't cause all of that. It's an HTTP reply with the 303
> and the new URL, followed by a single URL request from the browser.
>
OK. I think I know how other people (like you) think about just
requesting URL's one after another. If that's not such a performance
issue for you, fine.
A plain 303 redirect mostly isn't just a HTML file, it's another script
(or the same script with another action falling through a switch
statement, whatever).
Point is: why hitting you webserver with multiple requests per user,
just after submitting a form or whatever caused the redirect? If you
have 2 users per day, that won't hurt. But if you have 30.000 concurrent
users a minute, that could be 60.000 requests (besides all the images,
stylesheets, javascripts that are being re-requested). Or am I talking
nonsense?
--
Aschwin Wesselius
/'What you would like to be done to you, do that to the other....'/
attached mail follows:
On Mar 18, 2008, at 10:11 AM, Per Jessen wrote:
> Per Jessen wrote:
>
>> My typical setup for a form-page probably looks like this:
>>
>> if ( $_POST )
>> {
>> // do POST processing
>> header(303 thankyou.html).
>> exit
>> }
>
> If I wanted the user back on the same form page, but still with a
> "thank
> you" message, I'd still do a 303, but use $_SESSION to indicate that
> the user needs a "thank you" message displayed.
>
Just to play devils advocate and to try and understand things better...
Is there any reason you couldn't do a simple:
$formsubmitted= true;
if($formsubmitted = true){
Thank you for giving the bad guys your credit card number hahahahahah!
}else{
echo <<<HTML
<P>Give me your credit card number or I'll force you to eat raw spam
all day!</P><input type="text" name="txtCC"
}
Or something like that :)
>
> /Per Jessen, Zürich
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Jason Pruim
Raoset Inc.
Technology Manager
MQC Specialist
3251 132nd ave
Holland, MI, 49424-9337
www.raoset.com
japruimraoset.com
attached mail follows:
On Mar 18, 2008, at 10:08 AM, Aschwin Wesselius wrote:
> Per Jessen wrote:
>>
>>> header(location) mechanisms do come with a very huge disadvantage if
>>> you don't use them with caution. Requests are reinitialised,
>>> libraries
>>> loaded (again), DB connections setup/checked again, session lookups
>>> are being done, log write for another request etc. That's quite an
>>> impact for just not knowing what to do with flow.
>>
>> I'm having difficulties following you - a plain 303 redirect to a
>> "Thank
>> you" page shouldn't cause all of that. It's an HTTP reply with the
>> 303
>> and the new URL, followed by a single URL request from the browser.
>>
> OK. I think I know how other people (like you) think about just
> requesting URL's one after another. If that's not such a performance
> issue for you, fine.
>
> A plain 303 redirect mostly isn't just a HTML file, it's another
> script (or the same script with another action falling through a
> switch statement, whatever).
>
> Point is: why hitting you webserver with multiple requests per user,
> just after submitting a form or whatever caused the redirect? If you
> have 2 users per day, that won't hurt. But if you have 30.000
> concurrent users a minute, that could be 60.000 requests (besides
> all the images, stylesheets, javascripts that are being re-
> requested). Or am I talking nonsense?
I don't know much about the actual load stuff... but I do know unless
you specifically set it, the CSS should be cached unless you refresh
it and the date has changed on the file. I assume the same with the
images as well.
>
> --
>
> Aschwin Wesselius
>
> /'What you would like to be done to you, do that to the other....'/
--
Jason Pruim
Raoset Inc.
Technology Manager
MQC Specialist
3251 132nd ave
Holland, MI, 49424-9337
www.raoset.com
japruimraoset.com
attached mail follows:
On 18 Mar 2008, at 14:08, Aschwin Wesselius wrote:
> Per Jessen wrote:
>>
>>> header(location) mechanisms do come with a very huge disadvantage if
>>> you don't use them with caution. Requests are reinitialised,
>>> libraries
>>> loaded (again), DB connections setup/checked again, session lookups
>>> are being done, log write for another request etc. That's quite an
>>> impact for just not knowing what to do with flow.
>>
>> I'm having difficulties following you - a plain 303 redirect to a
>> "Thank
>> you" page shouldn't cause all of that. It's an HTTP reply with the
>> 303
>> and the new URL, followed by a single URL request from the browser.
>>
> OK. I think I know how other people (like you) think about just
> requesting URL's one after another. If that's not such a performance
> issue for you, fine.
>
> A plain 303 redirect mostly isn't just a HTML file, it's another
> script (or the same script with another action falling through a
> switch statement, whatever).
>
> Point is: why hitting you webserver with multiple requests per user,
> just after submitting a form or whatever caused the redirect? If you
> have 2 users per day, that won't hurt. But if you have 30.000
> concurrent users a minute, that could be 60.000 requests (besides
> all the images, stylesheets, javascripts that are being re-
> requested). Or am I talking nonsense?
What Per is saying is that you should be doing the minimum amount of
work possible to handle each request. If you have a shedload of code
that runs for every single page request regardless of what it's going
to do then your architecture sucks. If that is the case then avoiding
unnecessary bounces off the client is probably a good idea. If your
site is well-architected then redirects of this type will probably not
be a big performance drain.
One minor thing... a 303 redirect is permanent. In this situation you
want to use a 302 otherwise you could potentially cause problems with
proxies.
My opinion is that a redirect is the best way to prevent duplicate
posts. It prevents the user from getting the confusing popup and it
means you don't need to track whether a form has been posted yet. If
your application is well-architected you shouldn't need to worry about
performance.
-Stut
--
http://stut.net/
attached mail follows:
On 18 Mar 2008, at 14:49, Jason Pruim wrote:
> On Mar 18, 2008, at 10:11 AM, Per Jessen wrote:
>> Per Jessen wrote:
>>> My typical setup for a form-page probably looks like this:
>>>
>>> if ( $_POST )
>>> {
>>> // do POST processing
>>> header(303 thankyou.html).
>>> exit
>>> }
>>
>> If I wanted the user back on the same form page, but still with a
>> "thank
>> you" message, I'd still do a 303, but use $_SESSION to indicate that
>> the user needs a "thank you" message displayed.
>>
>
> Just to play devils advocate and to try and understand things
> better...
>
> Is there any reason you couldn't do a simple:
>
> $formsubmitted= true;
>
> if($formsubmitted = true){
> Thank you for giving the bad guys your credit card number
> hahahahahah!
> }else{
> echo <<<HTML
> <P>Give me your credit card number or I'll force you to eat raw spam
> all day!</P><input type="text" name="txtCC"
>
> }
> Or something like that :)
Because if the user reloads that page you'll process the form again,
which could have any number of nasty effects from creating a duplicate
row in the database to charging a credit card again. It also causes a
potentially confusing confirmation request to be displayed to the user.
-Stut
--
http://stut.net/
attached mail follows:
Quoting Aschwin Wesselius <aschwinilluminated.nl>:
> Per Jessen wrote:
>>
>>> header(location) mechanisms do come with a very huge disadvantage if
>>> you don't use them with caution. Requests are reinitialised, libraries
>>> loaded (again), DB connections setup/checked again, session lookups
>>> are being done, log write for another request etc. That's quite an
>>> impact for just not knowing what to do with flow.
>>
>> I'm having difficulties following you - a plain 303 redirect to a "Thank
>> you" page shouldn't cause all of that. It's an HTTP reply with the 303
>> and the new URL, followed by a single URL request from the browser.
>>
> OK. I think I know how other people (like you) think about just
> requesting URL's one after another. If that's not such a performance
> issue for you, fine.
People like who? Come on we try to help.
>
> A plain 303 redirect mostly isn't just a HTML file, it's another script
> (or the same script with another action falling through a switch
> statement, whatever).
A 303 is whatever you make of it.
>
> Point is: why hitting you webserver with multiple requests per user,
> just after submitting a form or whatever caused the redirect? If you
> have 2 users per day, that won't hurt. But if you have 30.000
> concurrent users a minute, that could be 60.000 requests (besides all
> the images, stylesheets, javascripts that are being re-requested). Or
> am I talking nonsense?
True. Why hit your webserver with useless requests.
But if you submit a form. There must be a action behind it .. right?
So you either reload the page, use header() or some other method. The
next page needs to be loaded. And so will CSS, JS, images.
> --
>
> Aschwin Wesselius
>
> /'What you would like to be done to you, do that to the other....'/
attached mail follows:
Stut wrote:
> One minor thing... a 303 redirect is permanent. In this situation you
> want to use a 302 otherwise you could potentially cause problems with
> proxies.
A redirect following a POST really should be a 303 - RFC 2616 :
10.3.4 303 See Other
The response to the request can be found under a different URI and
SHOULD be retrieved using a GET method on that resource. This method
exists primarily to allow the output of a POST-activated script to
redirect the user agent to a selected resource.
/Per Jessen, Zürich
attached mail follows:
On 18 Mar 2008, at 15:33, Per Jessen wrote:
> Stut wrote:
>
>> One minor thing... a 303 redirect is permanent. In this situation you
>> want to use a 302 otherwise you could potentially cause problems with
>> proxies.
>
> A redirect following a POST really should be a 303 - RFC 2616 :
>
> 10.3.4 303 See Other
>
> The response to the request can be found under a different URI and
> SHOULD be retrieved using a GET method on that resource. This method
> exists primarily to allow the output of a POST-activated script to
> redirect the user agent to a selected resource.
My bad. Confusing a 303 with a 301. It's been a long day. Etc.
-Stut
--
http://stut.net/
attached mail follows:
hi
my question is about displaying a friendly message when someone
directly types a url in the browser.
example i have one file called form.php which processes the
information entered in the form and lets say the next page is
thankyou.php?firstname=david
by seeing the url if someone types thankyou.php?firstname=smith in the
address bar the browser will display smith.
1. so if a user enters a url in the browser directly to a specific
page("thankyou.php") i would like to display a message like =
"Direct access to this file is not allowed"
2. with the above method assuming even if i type thankyou.php in the
browser directly, though i own the file i will also get the message
"Direct access to this file is not allowed". so i would not like to
see this message, i guess for this i need to specify my IP address i
suppose.
please provide answers for 1 and 2 points above.
thanks.
attached mail follows:
On 18 Mar 2008, at 12:46, Sudhakar wrote:
> my question is about displaying a friendly message when someone
> directly types a url in the browser.
>
> example i have one file called form.php which processes the
> information entered in the form and lets say the next page is
> thankyou.php?firstname=david
>
> by seeing the url if someone types thankyou.php?firstname=smith in the
> address bar the browser will display smith.
>
> 1. so if a user enters a url in the browser directly to a specific
> page("thankyou.php") i would like to display a message like =
> "Direct access to this file is not allowed"
It is not possible to do this reliably. You can check the HTTP_REFERER
variable in $_SERVER, but it's not guaranteed to exist and certainly
not guaranteed to be accurate.
I'm guessing you want to protect access to some restricted resource,
in which case you need to implement a server-side only check. The most
common way to do this is to use sessions. If someone hits the page
without a valid session you know they've not gone through the whole
process.
> 2. with the above method assuming even if i type thankyou.php in the
> browser directly, though i own the file i will also get the message
> "Direct access to this file is not allowed". so i would not like to
> see this message, i guess for this i need to specify my IP address i
> suppose.
That would be one way to do it, but bear in mind that any way you put
in to get around security is open to being exploited by other parties.
Think carefully about whether you actually need to hit that URL
directly all the time or just during development. If it's just during
development it would be better to disable any security features you've
implemented, just make sure you re-enable them before you put it live.
-Stut
--
http://stut.net/
attached mail follows:
Use sessions or (not as secure) pass a hidden form field along from form.php
to thankyou.php. You can look for it in thankyou.php and if it's not there
then you know something's wrong.
You'd check the $_POST array for your secret field and value.
\d
attached mail follows:
On 3/16/08, Ryan A <genphpyahoo.com> wrote:
>
> Now that thats over... can anybody recommend a good starting point to learn regex in baby steps?
>
> Cheers!
> R
Mastering Regular Expressions, by Jeffrey Friedl
ISBN 0-596-00289-0
--
-David.
When the power of love
overcomes the love of power,
the world will know peace.
-Jimi Hendrix
attached mail follows:
2008/3/17 Jonathan Crawford <jcrawf02baker.edu>:
>
> http://www.regular-expressions.info/php.html
I second http://www.regular-expressions.info/.
--
</Daniel P. Brown>
Forensic Services, Senior Unix Engineer
1+ (570-) 362-0283
attached mail follows:
I've encountered a situation where under PHP 5 the file_get_contents()
function will not work properly (actually not at all) if the php.ini
Filesystem configuration parameter, allow_url_include is set to OFF.
According to the PHP documentation allow_url_include is intended to
limiting PHP from accessing scripts on other servers.
I have read posts that suggest setting allow_url_include to ON as
a solution. Well that's great if you have the ability to modify your
php.ini. But what if you have an account on a shared hosting system
and the hosting company will NOT make the requested change?
Is there a work around to this or how would one access remote web services
if allow_url_include is OFF. This looks like a huge problem since many
services, like PayPal's IPN and Google maps geocoding, rely on communication
with their servers.
Thanks,
Chris
attached mail follows:
The actual setting is allow_url_fopen. allow_url_include controls whether
or not you can use a remote URL as an include (however, if allow_url_fopen
is off, then allow_url_include will also be off.)
The short answer to your question is: yes, there is a way. Several ways, in
fact. You could use curl, or you could use an Http client written in php.
The latter involves using either the socket_ or the fsocket functions.
* http://scripts.incutio.com/httpclient/
On Tue, Mar 18, 2008 at 10:11 AM, Chris <cwilli14rochester.rr.com> wrote:
> I've encountered a situation where under PHP 5 the file_get_contents()
> function will not work properly (actually not at all) if the php.ini
> Filesystem configuration parameter, allow_url_include is set to OFF.
> According to the PHP documentation allow_url_include is intended to
> limiting PHP from accessing scripts on other servers.
>
> I have read posts that suggest setting allow_url_include to ON as
> a solution. Well that's great if you have the ability to modify your
> php.ini. But what if you have an account on a shared hosting system
> and the hosting company will NOT make the requested change?
>
> Is there a work around to this or how would one access remote web services
> if allow_url_include is OFF. This looks like a huge problem since many
> services, like PayPal's IPN and Google maps geocoding, rely on
> communication
> with their servers.
>
> Thanks,
> Chris
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
attached mail follows:
Quoting Chris <cwilli14rochester.rr.com>:
> I've encountered a situation where under PHP 5 the file_get_contents()
> function will not work properly (actually not at all) if the php.ini
> Filesystem configuration parameter, allow_url_include is set to OFF.
> According to the PHP documentation allow_url_include is intended to
> limiting PHP from accessing scripts on other servers.
>
> I have read posts that suggest setting allow_url_include to ON as
> a solution. Well that's great if you have the ability to modify your
> php.ini. But what if you have an account on a shared hosting system
> and the hosting company will NOT make the requested change?
>
> Is there a work around to this or how would one access remote web services
> if allow_url_include is OFF. This looks like a huge problem since many
> services, like PayPal's IPN and Google maps geocoding, rely on communication
> with their servers.
>
Try ini_set("allow_url_include", "1"); In your script. (not tested)
If that doesn't help. You can use CURL for this :
http://php.net/manual/en/ref.curl.php
attached mail follows:
for security reasons, allow_url_include can only be set from the main
php.ini
On Tue, Mar 18, 2008 at 10:22 AM, Thijs Lensselink <devlenss.nl> wrote:
> Quoting Chris <cwilli14rochester.rr.com>:
>
> > I've encountered a situation where under PHP 5 the file_get_contents()
> > function will not work properly (actually not at all) if the php.ini
> > Filesystem configuration parameter, allow_url_include is set to OFF.
> > According to the PHP documentation allow_url_include is intended to
> > limiting PHP from accessing scripts on other servers.
> >
> > I have read posts that suggest setting allow_url_include to ON as
> > a solution. Well that's great if you have the ability to modify your
> > php.ini. But what if you have an account on a shared hosting system
> > and the hosting company will NOT make the requested change?
> >
> > Is there a work around to this or how would one access remote web
> services
> > if allow_url_include is OFF. This looks like a huge problem since many
> > services, like PayPal's IPN and Google maps geocoding, rely on
> communication
> > with their servers.
> >
>
> Try ini_set("allow_url_include", "1"); In your script. (not tested)
>
> If that doesn't help. You can use CURL for this :
> http://php.net/manual/en/ref.curl.php
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
attached mail follows:
Quoting Greg Bowser <topnotchergmail.com>:
> for security reasons, allow_url_include can only be set from the main
> php.ini
>
I wasn't sure about that one. Thanks for the correction.
> On Tue, Mar 18, 2008 at 10:22 AM, Thijs Lensselink <devlenss.nl> wrote:
>
>> Quoting Chris <cwilli14rochester.rr.com>:
>>
>> > I've encountered a situation where under PHP 5 the file_get_contents()
>> > function will not work properly (actually not at all) if the php.ini
>> > Filesystem configuration parameter, allow_url_include is set to OFF.
>> > According to the PHP documentation allow_url_include is intended to
>> > limiting PHP from accessing scripts on other servers.
>> >
>> > I have read posts that suggest setting allow_url_include to ON as
>> > a solution. Well that's great if you have the ability to modify your
>> > php.ini. But what if you have an account on a shared hosting system
>> > and the hosting company will NOT make the requested change?
>> >
>> > Is there a work around to this or how would one access remote web
>> services
>> > if allow_url_include is OFF. This looks like a huge problem since many
>> > services, like PayPal's IPN and Google maps geocoding, rely on
>> communication
>> > with their servers.
>> >
>>
>> Try ini_set("allow_url_include", "1"); In your script. (not tested)
>>
>> If that doesn't help. You can use CURL for this :
>> http://php.net/manual/en/ref.curl.php
>>
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
attached mail follows:
On Mar 17, 2008, at 10:34 AM, Mikey wrote:
> Shawn McKenzie wrote:
>> Daniel Brown wrote:
>>> On Sun, Mar 16, 2008 at 4:18 PM, Casey <heavyccaseygmail.com>
>>> wrote:
>>>> Hi list!
>>>>
>>>> __halt_compiler(). Does anyone use it?
>>>>
>>>> I've used it obsessively in my past two "projects" to store data
>>>> (specifically CSV) in the PHP files. These two "projects"
>>>> consisted of
>>>> only one file, and I didn't want to clutter everything and involve
>>>> databases and/or XML files.
>>>>
>>>> Your thoughts?
>>> In my opinion, if you're distributing open source scripts or the
>>> like, and wanted to send out a really simple installer package, that
>>> would be fine. All-in-all, you want to evaluate the scope of your
>>> code, the knowledge level of your user base, the means by which the
>>> code will be shared, et cetera. It's really up to your best
>>> educated
>>> judgment on a per-project basis.
>>>
>>> Now, the world don't move to the beat of just one drum. What
>>> might be right for you may not be right for some: a man is born,
>>> he's
>>> a man of means. Then along come two and they've got nothing but
>>> their
>>> genes, but they've got Diff'rent Strokes. It takes Diff'rent
>>> Strokes.
>>> It takes Diff'rent Strokes to move the world.
>>>
>>> Everybody's got a special kind of story. Everybody finds their
>>> way to shine. It don't matter that you got not a lot; so what?
>>> They'll have theirs and you'll have yours and I'll have mine. And
>>> together, we'll be fine! 'Cause it takes Diff'rent Strokes to move
>>> the world.
>>>
>>> Yes, it does, it takes Diff'rent Strokes to move the world.
>>>
>> What you talk'n about Willis?
>
> (tugs on cheeky cheeks!)
Yeah, I wasn't sure whether I was supposed to raise my lighter or cry...
~Philip
attached mail follows:
I've been reading up on some of the parts of PHP that has been suggested
could be improved so that I could be more well informed. One of the
more "interesting" (for lack of a better word) suggestions is closures.
I've used closures primarily in JavaScript, and they are handy in that
context, but JavaScript handles events and other more dynamic situations
like that.
I can't really think of any good examples of why I'd want to use a
closure instead of just calling functions or class methods in PHP.
Variable functions and call_user_func*() have worked for any of the
cases where I did need to be a bit more dynamic.
I found a great summary of some discussion on the internals mailing list
over here: http://devzone.zend.com/node/view/id/2013#Heading1
After reading that article through, I do like Wez's idea of how to
create anonymous functions. The point about it causing confusion with
people coming from other languages definitely applies though. This
article also gives me a second idea for this post. How many people
would want closures in PHP?
In summary:
Would you want closures in PHP, and why?
--
Ray Hauge
www.primateapplications.com
attached mail follows:
> > Somehow it is getting to this statement and the variable that you
> > are using just before the ORDER BY part is empty, Why don't you
> > show us that statement.
>
> Requested statement below:
>
> $query = "SELECT * from ".$linkauth['table']." order by ".$sortOrder;
>
> The $linkauth['table'] is returned when the authentication is
> successful. Otherwise it's not written so that you have to log in to
> see the contents of the database.
Sorry, havn't had a ton of time to go over mailing list messages recently.
If I recall, you said that the big issue was that this query shouldn't run
if the user isn't logged in. So that would point to an issue with your
logic before you get to this point. You might see where you're checking
for the user being logged in or not and make sure everything is within the
proper "if" grouping.
This specific query and the reason you're getting that MySQL error is
probably because when a user isn't logged in, your $linkauth['table']
variable is empty. So what you're getting for a SQL statement is:
SELECT * from order by <$sortOrder if it's populated>
If you fix your "user is/isn't logged in" conditional statement so it doesn't
get to this SQL query, then you won't have to worry about this error.
You can also check to make sure $linkauth['table'] has something in it before
running the query.. skip it if it's empty or has an invalid table name.
-TG
attached mail follows:
what started out as a simple little reply bloated out into an inpromptu brain
fart ... lots of bla .. enjoy :-)
Jason Pruim schreef:
> Hi everyone,
>
> I am attempting to add a little error checking for a very simple login
> system. The info is stored in a MySQL database, and I am using mysqli to
> connect to it. I have it working with the solution provided below, but I
> am wondering if this is the right way to do it or if there is a better way?
at an abstract level you might consider that your function could simply
always return a boolean (true = logged in, false = not logged in) and that the
rest of the application retrieves all the other data via the session
(as opposed to returning half the data and storing half in the session)
if you choose to store everything and only return authentication state you
might also consider to abstract the storage somewhat so that other code doesn't
have to access the session data directly. we call this concept 'loose coupling'.
for instance:
function getUserInfo($key = null)
{
if (!isset($_SESSION['user']['loggedin']))
return null;
if (!$_SESSION['loggedin'])
return null;
$key = trim((string)$key);
if ($key == '')
return $_SESSION['user'];
if (isset($_SESSION['user'][$key]))
return $_SESSION['user'][$key];
return null;
}
this example still requires that the the consumer of getUserInfo() knows
the names of the relevant columns (from multiple tables?) .. this could also
be abstracted, a simple solution would be something like:
// put these in a config file, (CKEY = 'cache key' ... just a thought)
define('CKEY_USER_NAME', 'loginName');
define('CKEY_USER_LEVEL', 'adminLevel');
define('CKEY_USER_TABLE', 'tableName');
$uName = getUserInfo( CKEY_USER_NAME );
$uLevel = getUserInfo( CKEY_USER_LEVEL );
$uLevel = getUserInfo( CKEY_USER_TABLE );
... you get? ... incidentally your column names seem to be case-sensitive,
I recommend lower or upper (depending on DBMS) case only for sql entity names
for two reasons:
1. you avoid nitpicky irritations due to SQL case-sensitivity related bugs
in your code.
2. if you lowercase all entity names you can write stuff like so:
$sql = "SELECT foo, bar FROM qux WHERE abc = 1 AND def=2";
which is a little more readable than this:
$sql = "SELECT FOO, BAR FROM QUX WHERE ABC = 1 AND DEF=2";
of course it should be more like:
$sql = "SELECT `foo`, `bar` FROM `qux` WHERE `abc`=1 AND `def`=2";
using case to differentiate between SQL and entity names becomes more useful
as the queries become more complex. I also tend to then break then up into lines:
$sql = "SELECT
q.`foo', q.`bar`,
na.`foo` AS nafoo, na.`bar` AS nabar,
noo.`foo` AS noofoo, noo.`bar` AS noobar,
FROM
`qux` AS q
LEFT JOIN
`na` AS na ON na.`qux_id` = q.`id`
LEFT JOIN
`noo` AS noo ON noo.`qux_id` = q.`id`
WHERE
(`abc`=? AND `def`=?)
AND
q.`id` IN (SELECT `qux_id` FROM `quxnobbins` WHERE `nobbin_id`=?)
AND (
(`start_date` BETWEEN ? AND ?) OR
(`start_date` BETWEEN ? AND ?)
)";
>
> My thinking with this is if more then 1 record is returned from the
> database, then there is a issue... If only is returned then the
> username/password matched and I can safely show them the info...
>
> $rowcnt = mysqli_num_rows($loginResult);
we'll assume the original sql was suitably prepared (i.e. user values escaped, etc).
but why not 'fix' the query and/or table so that it will only ever return one row?
> if($rowcnt !="1"){
avoid auto-casting!
if ($rowcnt !== 1) { /*...*/ }
> echo "Auth failed";
> die("Auth failed... Sorry");
>
>
>
> }else{
> while($row1 = mysqli_fetch_array($loginResult)) {
this 'while' is completely pointless, you know there is just one row,
no point in looping for a single iteration.
just do:
$row = mysqli_fetch_array($loginResult);
$_SESSION['user'] = $row['loginName'];
// ... etc
> $_SESSION['user'] = $row1['loginName'];
> $_SESSION['loggedin'] = "YES";
"YES" is not a boolean value, I think $_SESSION['loggedin'] should be
boolean (you got deja vu here also?).
check the following code to see why:
$_SESSION['loggedin'] = "FALSE";
if ($_SESSION['loggedin'])
echo "your logged in!";
> $table = $row1['tableName'];
> $adminLevel = $row1['adminLevel'];
> $authenticated = "TRUE";
again the boolean should be boolean!
> echo "<BR>authentication complete";
with regard to seperation of responsibilities: the function should
really be either attempting an authentication *or* outputting some message
regarding the result of the authentication attempt but *not* both.
in practice this means my recommendation would be to remove the echo statements
from the function and have the code that calls this function be responsible for
outputting feedback ... imagine if you need to, someday, perform an authentication
without [direct] output? or you need to change the outputted message under certain
conditions (conditions which are outside the scope of this function)?
a function should, as much as is possible, do one thing only (and do it well), otherwise,
I guess, it would be called a functions. ;-)
> }
> return Array($table, $authenticated, $adminLevel);
pretty much the rest of the world writes 'Array()' as 'array()' .. the convention
being that built in functions and lang constructs are always typed lowercase. some
people write things like isSet($foo); ... but they are 'wrong' :-)
I generally try to distinguish between userland and php functions by using lowercase
for php funcs and CamelCase naming schemes for userland functions.
--
"ok, porky pig say your line."
attached mail follows:
On Mar 18, 2008, at 3:20 PM, Jochem Maas wrote:
> what started out as a simple little reply bloated out into an
> inpromptu brain
> fart ... lots of bla .. enjoy :-)
>
> Jason Pruim schreef:
>> Hi everyone,
>> I am attempting to add a little error checking for a very simple
>> login system. The info is stored in a MySQL database, and I am
>> using mysqli to connect to it. I have it working with the solution
>> provided below, but I am wondering if this is the right way to do
>> it or if there is a better way?
>
> at an abstract level you might consider that your function could
> simply
> always return a boolean (true = logged in, false = not logged in)
> and that the
> rest of the application retrieves all the other data via the session
> (as opposed to returning half the data and storing half in the
> session)
I think this is what I am attempting to do... Just going about it all
wrong...
I want the pages to check to see if the person is still logged in and
if they are, then it's pulling live data from the database... So
maybe I should edit my authentication function...
function auth($loggedin) {
query database to see if username & Password match;
write certain variables into session (Or maybe into the cache?)
return true if it matches
if not return false which could then redirect back to login page...
}
Is it that simple? Am I trying to make things so much more complicated?
>
>
> if you choose to store everything and only return authentication
> state you
> might also consider to abstract the storage somewhat so that other
> code doesn't
> have to access the session data directly. we call this concept
> 'loose coupling'.
> for instance:
>
> function getUserInfo($key = null)
> {
> if (!isset($_SESSION['user']['loggedin']))
> return null;
>
> if (!$_SESSION['loggedin'])
> return null;
>
> $key = trim((string)$key);
>
> if ($key == '')
> return $_SESSION['user'];
>
> if (isset($_SESSION['user'][$key]))
> return $_SESSION['user'][$key];
>
> return null;
> }
>
> this example still requires that the the consumer of getUserInfo()
> knows
> the names of the relevant columns (from multiple tables?)
login info is stored on 1 table, while the actual records in the DB
are stored on another table. After successful login it changes from
the login table to the data table.
> .. this could also
> be abstracted, a simple solution would be something like:
>
> // put these in a config file, (CKEY = 'cache key' ... just a thought)
> define('CKEY_USER_NAME', 'loginName');
> define('CKEY_USER_LEVEL', 'adminLevel');
> define('CKEY_USER_TABLE', 'tableName');
>
>
> $uName = getUserInfo( CKEY_USER_NAME );
> $uLevel = getUserInfo( CKEY_USER_LEVEL );
> $uLevel = getUserInfo( CKEY_USER_TABLE );
And then that would hold the info in a cache until the user hit logout
and then logged back in? I'm going to try that right after sending
this message.... That may work perfectly...
Also I'm assuming if I put these into an include file it will work
just like my other variables where I can call $pass from any page that
includes the file $pass is defined in?
>
>
> ... you get? ... incidentally your column names seem to be case-
> sensitive,
> I recommend lower or upper (depending on DBMS) case only for sql
> entity names
> for two reasons:
>
> 1. you avoid nitpicky irritations due to SQL case-sensitivity
> related bugs
> in your code.
>
> 2. if you lowercase all entity names you can write stuff like so:
>
> $sql = "SELECT foo, bar FROM qux WHERE abc = 1 AND def=2";
>
> which is a little more readable than this:
>
> $sql = "SELECT FOO, BAR FROM QUX WHERE ABC = 1 AND DEF=2";
>
> of course it should be more like:
>
> $sql = "SELECT `foo`, `bar` FROM `qux` WHERE `abc`=1 AND `def`=2";
>
> using case to differentiate between SQL and entity names becomes
> more useful
> as the queries become more complex. I also tend to then break then
> up into lines:
>
> $sql = "SELECT
> q.`foo', q.`bar`,
> na.`foo` AS nafoo, na.`bar` AS nabar,
> noo.`foo` AS noofoo, noo.`bar` AS noobar,
> FROM
> `qux` AS q
> LEFT JOIN
> `na` AS na ON na.`qux_id` = q.`id`
> LEFT JOIN
> `noo` AS noo ON noo.`qux_id` = q.`id`
> WHERE
> (`abc`=? AND `def`=?)
> AND
> q.`id` IN (SELECT `qux_id` FROM `quxnobbins` WHERE `nobbin_id`=?)
> AND (
> (`start_date` BETWEEN ? AND ?) OR
> (`start_date` BETWEEN ? AND ?)
> )";
>
>
>
>> My thinking with this is if more then 1 record is returned from the
>> database, then there is a issue... If only is returned then the
>> username/password matched and I can safely show them the info...
>> $rowcnt = mysqli_num_rows($loginResult);
>
> we'll assume the original sql was suitably prepared (i.e. user
> values escaped, etc).
> but why not 'fix' the query and/or table so that it will only ever
> return one row?
>
>> if($rowcnt !="1"){
>
> avoid auto-casting!
>
> if ($rowcnt !== 1) { /*...*/ }
>
>> echo "Auth failed";
>> die("Auth failed... Sorry");
>> }else{
>> while($row1 = mysqli_fetch_array($loginResult)) {
>
> this 'while' is completely pointless, you know there is just one row,
> no point in looping for a single iteration.
Will make that change now :)
>
>
> just do:
>
> $row = mysqli_fetch_array($loginResult);
> $_SESSION['user'] = $row['loginName'];
> // ... etc
>
>
>> $_SESSION['user'] = $row1['loginName'];
>> $_SESSION['loggedin'] = "YES";
>
> "YES" is not a boolean value, I think $_SESSION['loggedin'] should be
> boolean (you got deja vu here also?).
Just to double check: $_SESSION['loggedin'] = TRUE; //Is a boolean
while:
$_SESSION['loggedin'] = "TRUE"; // is not correct?
>
>
> check the following code to see why:
>
> $_SESSION['loggedin'] = "FALSE";
> if ($_SESSION['loggedin'])
> echo "your logged in!";
>
>
>
>> $table = $row1['tableName'];
>> $adminLevel = $row1['adminLevel'];
>> $authenticated = "TRUE";
>
> again the boolean should be boolean!
>
>> echo "<BR>authentication complete";
>
> with regard to seperation of responsibilities: the function should
> really be either attempting an authentication *or* outputting some
> message
> regarding the result of the authentication attempt but *not* both.
That was added for debugging, helping me track down where the error was.
>
>
> in practice this means my recommendation would be to remove the echo
> statements
> from the function and have the code that calls this function be
> responsible for
> outputting feedback ... imagine if you need to, someday, perform an
> authentication
> without [direct] output? or you need to change the outputted message
> under certain
> conditions (conditions which are outside the scope of this function)?
>
> a function should, as much as is possible, do one thing only (and do
> it well), otherwise,
> I guess, it would be called a functions. ;-)
>
>> }
>> return Array($table, $authenticated, $adminLevel);
>
> pretty much the rest of the world writes 'Array()' as 'array()' ..
> the convention
> being that built in functions and lang constructs are always typed
> lowercase. some
> people write things like isSet($foo); ... but they are 'wrong' :-)
I thought I saw on the php.net page that it was Array() :)
>
>
> I generally try to distinguish between userland and php functions by
> using lowercase
> for php funcs and CamelCase naming schemes for userland functions.
I see what you're getting at though... And I need to do that more
through my applications..
>
>
> --
> "ok, porky pig say your line."
>
--
Jason Pruim
Raoset Inc.
Technology Manager
MQC Specialist
3251 132nd ave
Holland, MI, 49424-9337
www.raoset.com
japruimraoset.com
attached mail follows:
On Mar 18, 2008, at 12:26 PM, TG wrote:
>
>>> Somehow it is getting to this statement and the variable that you
>>> are using just before the ORDER BY part is empty, Why don't you
>>> show us that statement.
>>
>> Requested statement below:
>>
>> $query = "SELECT * from ".$linkauth['table']." order by ".$sortOrder;
>>
>> The $linkauth['table'] is returned when the authentication is
>> successful. Otherwise it's not written so that you have to log in to
>> see the contents of the database.
>
>
> Sorry, havn't had a ton of time to go over mailing list messages
> recently.
> If I recall, you said that the big issue was that this query
> shouldn't run
> if the user isn't logged in. So that would point to an issue with
> your
> logic before you get to this point. You might see where you're
> checking
> for the user being logged in or not and make sure everything is
> within the
> proper "if" grouping.
>
>
> This specific query and the reason you're getting that MySQL error is
> probably because when a user isn't logged in, your $linkauth['table']
> variable is empty. So what you're getting for a SQL statement is:
>
> SELECT * from order by <$sortOrder if it's populated>
I think you're spot on here... Time to revisit my authentication
function and see if I can streamline it :)
--
Jason Pruim
Raoset Inc.
Technology Manager
MQC Specialist
3251 132nd ave
Holland, MI, 49424-9337
www.raoset.com
japruimraoset.com
attached mail follows:
I have created a XML string using PHP DOM. However when I send it to a third
party using curl it shows up as part of an array and cannot be read. How
should I be using curl to post a xml file.
My code is below
[code]
<?php
Require 'createxml.php';
$Result = simplexml_load_string($result);
$xmlResult= $Result->asXML();
$ch= curl_init();
curl_setopt($ch, CURLOPT_HTTPHEADER, Array("Content-Type: text/xml"));
curl_setopt($ch, CURLOPT_HTTPHEADER, Array("Accept: text/xml"));
curl_setopt($ch, CURLOPT_URL, "http://testurl.com");
curl_setopt($ch, CURLOPT_POSTFIELDS, $xmlResult);
curl_setopt($ch, CURLOPT_POST,1);
curl_exec($ch);
[/code]
Any help would be appreciated.
--
View this message in context: http://www.nabble.com/Problems-posting-xml-file-with-curl-and-php-tp16129807p16129807.html
Sent from the PHP - General mailing list archive at Nabble.com.
attached mail follows:
On Tue, Mar 18, 2008 at 4:26 PM, michaelh613 <
michaelyourcomputerconsultant.com> wrote:
>
> I have created a XML string using PHP DOM. However when I send it to a
> third
> party using curl it shows up as part of an array and cannot be read. How
> should I be using curl to post a xml file.
>
> My code is below
> [code]
> <?php
> Require 'createxml.php';
> $Result = simplexml_load_string($result);
> $xmlResult= $Result->asXML();
> $ch= curl_init();
> curl_setopt($ch, CURLOPT_HTTPHEADER, Array("Content-Type: text/xml"));
> curl_setopt($ch, CURLOPT_HTTPHEADER, Array("Accept: text/xml"));
> curl_setopt($ch, CURLOPT_URL, "http://testurl.com");
> curl_setopt($ch, CURLOPT_POSTFIELDS, $xmlResult);
> curl_setopt($ch, CURLOPT_POST,1);
> curl_exec($ch);
> [/code]
CURLOPT_POSTFIELDS must be specified as an array, therefore you will need to
conjure up some identifier and place it your xml in an array as follows,
curl_setopt($ch, CURLOPT_POSTFIELDS, array('xml' => $xmlResult));
-nathan
attached mail follows:
I've actually tried that and it didn't work for the server I am sending
it to. Is there a way to post just the xml without turning it into an
array or is this the only way.
Nathan Nobbe wrote:
> On Tue, Mar 18, 2008 at 4:26 PM, michaelh613
> <michaelyourcomputerconsultant.com
> <mailto:michaelyourcomputerconsultant.com>> wrote:
>
>
> I have created a XML string using PHP DOM. However when I send it
> to a third
> party using curl it shows up as part of an array and cannot be
> read. How
> should I be using curl to post a xml file.
>
> My code is below
> [code]
> <?php
> Require 'createxml.php';
> $Result = simplexml_load_string($result);
> $xmlResult= $Result->asXML();
> $ch= curl_init();
> curl_setopt($ch, CURLOPT_HTTPHEADER, Array("Content-Type: text/xml"));
> curl_setopt($ch, CURLOPT_HTTPHEADER, Array("Accept: text/xml"));
> curl_setopt($ch, CURLOPT_URL, "http://testurl.com");
> curl_setopt($ch, CURLOPT_POSTFIELDS, $xmlResult);
> curl_setopt($ch, CURLOPT_POST,1);
> curl_exec($ch);
> [/code]
>
>
> CURLOPT_POSTFIELDS must be specified as an array, therefore you will
> need to conjure up some identifier and place it your xml in an array
> as follows,
>
> curl_setopt($ch, CURLOPT_POSTFIELDS, array('xml' => $xmlResult));
>
> -nathan
>
attached mail follows:
On Tue, Mar 18, 2008 at 4:37 PM, Michael Horowitz <
michaelyourcomputerconsultant.com> wrote:
> I've actually tried that and it didn't work for the server I am sending
> it to. Is there a way to post just the xml without turning it into an
> array or is this the only way.
i dont know how to do it w/ the standard curl functions in php, but you can
do it w/ the http extension via
HttpRequest::addRawPostData()
http://us3.php.net/manual/en/function.HttpRequest-addRawPostData.php
-nathan
attached mail follows:
Not much documentation there. How would this function be integrated
with curl. my quick google doesn't show much discussion of this function.
Michael Horowitz
Your Computer Consultant
http://yourcomputerconsultant.com
561-394-9079
Nathan Nobbe wrote:
> On Tue, Mar 18, 2008 at 4:37 PM, Michael Horowitz
> <michaelyourcomputerconsultant.com
> <mailto:michaelyourcomputerconsultant.com>> wrote:
>
> I've actually tried that and it didn't work for the server I am
> sending
> it to. Is there a way to post just the xml without turning it into an
> array or is this the only way.
>
>
> i dont know how to do it w/ the standard curl functions in php, but
> you can do it w/ the http extension via
> HttpRequest::addRawPostData()
>
> http://us3.php.net/manual/en/function.HttpRequest-addRawPostData.php
>
> -nathan
attached mail follows:
On Tue, Mar 18, 2008 at 5:22 PM, Michael Horowitz <
michaelyourcomputerconsultant.com> wrote:
> Not much documentation there. How would this function be integrated
> with curl. my quick google doesn't show much discussion of this function.
i think this should be easier for you, http_post_data(), however its also
part of the http (pecl) extension, so youll have to install the extension to
use it.
http://us.php.net/manual/en/function.http-post-data.php
-nathan
ps.
please dont top-post ;)
attached mail follows:
Looks like I will be unable to use PHP5 to do a SOAP server. I believe
it was possible to do such a thing in PHP4, but perhaps not as
cleanly. Unfortunately, I am unable to locate the appropriate
documentation on php