Re: What is the best way to protect the PHP page that returns the AJAX data?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 10, 2007 10:18 pm, Daevid Vincent wrote:
> Like most sites, someone needs to join up to use mine.

Errr.

To be pedantic, I don't think "most" sites require registration,
actually... :-)

I'm not saying it's "bad" or anything, just that there's still way
more HTML pages out there with free access and no registration than
pages that require registration -- and I do think that fact that
there's more "free" stuff than "requires registration" stuff is a very
good thing, on the whole.

> I'm using a wee-bit-o-AJAX to pull some results from a database and
> display them dynamically.
>
> For the AJAX to work, it has to hit a script that's accessible from
> the htdocs tree right?

Well...

It has to be accessible from *SOME* htdocs tree *somewhere*.

Doesn't *have* to be the same doctree, nor even the same server.

Though the browser might warn the user that you're maybe trying to
"fool" them if the feeds don't all come from the same domain, and if
you don't jump through Javascript hoops to explicitly allow yourself
to use multiple domains...

> Effectively it's just a (JavaScript initiated) GET URL request
> correct?

Yes.

Or it could be POST, I presume, if you wanted.

Technically, I suppose it could even be HEAD or PUT or something even
more esoteric...

> For example, index.html calls
> http://example.com/gimmedata.php?query=foo
> That in turn returns a JS formatted array which is eval() in JS and
> rendered on the page.

You don't HAVE to return actual JS code.

You could return XML and have JS process the XML.

Or there's some nifty JSON data form expressly made-up for AJAX, as I
understand it.
http://php.net/json

> My question is, how do you protect gimmedata.php since it's sitting
> out there sans normal web headers and stuff?

Well, you definitely won't protect it at all if it's "out there"
without requiring the login, so don't do that.

Require the login, then figure out how to get the JS to be
authenticated, without exposing the user's password in the process.

> Can it include session_start() and do all that wonderful checking to
> make sure the user is logged in before just happily doling out
> my precious data?

Sure.  But then your JS has to be ready to send the cookies and all
that...

I presume that's the grunge stuff the AJAX framework thingies handle
for you.

Or you can find JS code to do it in seconds of googling.

It's not exactly rocket science.

AJAX is just like curl, only not, and on the browser side from
JavaScript instead of server-side from PHP, if that helps. :-)

> What is the proper, secure, sanctioned and AJAX/PHP blessed way to do
> this?

How secure is "secure enough"?

Are you passing around financial instruments -- actual money?

Is it medical data?

Confidential peronsal information?

Super-expensive subscription data worth thousands of dollars?

Nobody can answer this for you until you explicitly state just how
secure is secure enough, and for all of the above, the answer might be
"just don't do that"...

If it's not *that* sensitive, then a standard cookie session should be
enough for *most* uses.

Maybe you'll want to use SSL to protect the data in transit.

> I could set up a test environment and hack up something I'm sure --
> and probably will if I get too impatient, but nobody seems to
> address this issue in any examples, they just do it as if information
> is *gasp* free. I'm a PHP guru, but I am also an AJAX novice.
> From what I gather, the return is really in XML transport format and
> all the magic of converting to/from XML is transparent to me. I
> worry that putting other headers or whatever may "corrupt" that?

The AJAX thingies I've seen are using XmlHttpRequest object, which is
*expecting* an HTTP response...

So it's expecting the usual headers you're thinking of.

So if you don't have them, or at least some of them, it most likely
won't work at all.

Whether it will handle the cookies or HTTP Basic Auth properly or not
is up the the AJAX framework or your XmlHttpRequest-handling code...

You either send the cookies or Auth credentials, or it won't work.

-- 
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux