[quoted text, click to view] "Julian" <me@tech-pro.invalid> wrote in message
news:eLLYg1ohEHA.3932@TK2MSFTNGP09.phx.gbl...
> Ken Schaefer wrote:
>
>> There is no requirement that a HTTP client (eg a browser) send a
>> referer header - most do though. However, some people have software
>> installed (usually these SOHO "security suites" like Symantec
>> Internet Security etc) that "blocks" the client from sending out the
>> HTTP referer as a "privacy" measure (these programs may also block
>> cookies etc). This would be the most likely cause in my opinion.
>>
>> Cheers
>> Ken
>
> Ken, thanks!
>
> The problem did indeed turn out to be someone using Norton Firewall.
>
> I probably need to find a more appropriate newsgroup for my next
> question, which is how can my CGI script check that it is only being
> called from one of my own web pages if it can't rely on getting the
> referer information?
HTTP is stateless, so there's no 100% gauranteed way you can do this.
a) you can set a cookie
b) you can pass information in the querystring etc
Both can be spoofed by malicious users, but you can make it quite difficult.
For example, create a temporary session for the user using a GUID as a key,
and then roundtrip this to the client via a cookie. On the next page,
validate that the client is returning a valid cookie value. However,
client's that are blocking cookies (again using things like Norton Firewall)
will not be able to use your page.
If you really require a stateful solution, you need to look at using Java
applets, Flash controls or ActiveX plugins - things that can maintain a
continuous connection back to the server.
Cheers
Ken