John Allsopp wrote:
Robert Cummings wrote:
Ashley Sheridan wrote:
On Fri, 2010-02-12 at 16:12 -0500, Robert Cummings wrote:

John Allsopp wrote:
Hi everyone

There may be blinding bits of total ignorance in this so don't ignore the obvious.

This is a security question, but a sentence of background: I'm writing software for a mapping/location website and I want to be able to provide something others can plug into their website that would display their map.

So I'm providing a URL like

The idea is they can define their own height and width and it plugs in as an iframe.

That takes the username and password and throws it over web services to get back the data from which we can create the map.

My question (and it might be the wrong question) is how can I not give away the password to all and sundry yet still provide a self-contained URL?
MD5() (or SHA()) hash the information and supply that along with the settings. Then you know it was generated by your site. So you can do the following:


$height = 300;
$width = 250;
$username = 'username';
$key = md5( "SECRET_SALT-$heigh-$width-$username" );

$url = "$height&w=$width&username=$username&key=$key";;


Then when you get this URL via the iframe, you re-compute the expected key and then compare it against the given key. Since only you know the SECRET_SALT value then nobody should be able to forge the key.

Application and Templating Framework for PHP

What about requiring them to sign in the first time to use your service,
and then give them a unique id which i tied to their details. You could
then get them to pass across this id in the url. You could link their
account maybe to some sorts of limits with regards to what they can
access maybe?
Presumably they ARE logged in when you create this URL for them... otherwise someone else could generate it :)

Well no they are not logged in, it's just an embedded iframe so that's my main issue with my method, anyone could look at the web page source, pinch the URL of the iframe and they'd have the username and password.

I'd got as far as MD5, but not the Secret Salt bit.

The thing that warped my head was .. if the URL then becomes$height&w=$width&username=$username&key=$key that's the same thing isn't it .. a URL anyone could use anywhere? In a sense, we would have simply created another password, the MD5 key, which was a valid way to get into the system.

So then validating the domain from a list stops anyone using it anywhere and means we can switch it off by domain if we need to.

And .. we're not passing the password, right? We're not mixing that into the MD5? We are just saying, if you have the right username, if we know you've come via our code (secret salt), and you're from an approved domain, we'll let you in.

Sorted, I think .. unless you spot any faulty reasoning in the above. Thanks very much guys :-)

I should have been clearer... the $key part means they don't need to be logged in, only that the URL was generated from a trusted location. Presumably that location gained the trust of the person requesting the URL in some manner... whether it be that they logged in, or that it automatically generated the URL for them based on some other criteria. The $key just embodies that relationship. The salt is necessary so that not just anyone can generate the key since then anyone can generate the URL and thus anyone can set the parameters as they please. This may not be important in your case, but you seemed to think it was important enough to originally consider their password :) This technique is also good for displaying images on your site that you don't want other sites linking to. You would hash in a timestamp and then if the requested time exceeds the timestamp and duration you can serve up a "Sorry that image is only available at".

Application and Templating Framework for PHP

PHP General Mailing List (
To unsubscribe, visit:

Reply via email to