Re: what's the referer of an applet ?
On May 15, 9:48 am, LC's No-Spam Newsreading account
<nos...@mi.iasf.cnr.it> wrote:
I have a web pagehttp://somehost/somewhere.htmlwhich contains an
applet (the applet jar is now signed).
<APPLET CODE=myApplet24.class ARCHIVE=myApplet24.jar WIDTH=768
HEIGHT=850></APPLET>
The applet receives from a servlet an URL of a binary data file. It then
opens a stream, and reads from the URL to display the data with
DataInputStream in = new DataInputStream (new BufferedInputStream(
url.openStream(), 2880));
The same data files were previously (and still are) also "published" by
some other servlet for direct download ("old servlet" below).
The URL is of the formhttp://someotherhost/somepath/xx_tn.fits
On someotherhost an apache httpd is running. The .../somepath directory
originally contained a .htaccess which denies access to the data files
unless one comes from some specific page (as generated by the "old
servlet"). This occurs via a specific (combination of) SetEnvIf
directives.
SetEnvIf Referer xxxxxxx okincoming
...
deny from all
allow from env=okincoming
This prevents people to bookmark the data files and access them if they
are not logged in the old servlet.
Why?
Now the request from the applet is denied.
While I was testing the applet, my workaround was to allow incoditional
access from my machine, including in the .htaccess
SetEnvIf Remote_Addr 155.253.xx.xx okappletb
...
allow from env=okappletb
Now I want a more general way of allowing the applet to access the data
files irrespective of where the applet runs.
But the applet has no referer info. My apache log contains lines of the
form (it is the so called "combined log")
(1) (2-3) (4) (5) (6) (7) (8) (9)=
host - - [date] "GET url HTTP/1.1" 200 17280 "-" "Java/1.4.2_04"
host - - [date] "GET url HTTP/1.1" 200 17280 "-" "Mozilla/4.0 (Linux
2.6.8-24-smp) Java/1.4.2_05"
The Referer is column 8, and for requests coming from the applet is "-".
I cannot find a syntax in .htaccess which recognises such Referer,
- is the log marker indicating that the request did not have a Referer
header. To test for no-referer, you need to be somewhat indirect:
SetEnv hasreferer 0
SetEnvIf Referer .* hasreferer=1
# And optionally
# SetEnvIf hasreferer 0 noreferer=1
The column (9) contains the User-Agent issuing the request. It can occur
in the two forms shown above. The first form "Java/1.4.2_04" is a
request from my new servlet (it verifies the existence of the URL before
passing it to the applet".
The second form "Mozilla/4.0 (Linux 2.6.8-24-smp) Java/1.4.2_05" is a
request from the applet.
So far I was able to open access inserting in .htaccess
SetEnvIf User-Agent .*Java\.* okappleta
...
allow from env=okappleta
However I'd like to implement a more restrictive check. I do not want to
be open to ANY access from a Java servlet or applet, but just to
specific ones.
You cannot achieve this, as nothing prevents arbitrary HTTP clients
from lying to you about their User-Agent or Referer. Referer and User-
Agent are explicitly not reliable, and there cannot logically be a
reliable replacement for them.
The only parts of the request suitable for access control are the
connection's originating IP and the Authorization headers.
Authorization is only suitable if the authorization credentials come
from the user or some external auth agent; packaging credentials
inside the app is equivalent to providing no access control at all.
1) how can I force the applet to declare a specific Referer ?
By adding the Referer: header to its request. If you're using
URLConnection, see the setRequestProperty and addRequestProperty
methods. If you're using some other HTTP library, see the docs on how
to set request headers.
2) how can I combine two tests in .htaccess, i.e. how do I do
SetEnvIf Referer is something AND User-Agent is something then ok
Nothing in the Apache manual leaps out at me. Have you tried an Apache
HTTPD newsgroup or mailing list?
3) in principle, how do I declare a Referer in the servlet (the
servlet issues the same open stream statement followed by a close(=
)
and uses a catch (Exception e) to tell if the URL is failing) ?
By adding the Referer: header to its request.
You would be very well served by reading RFC 2616, which defines
HTTP. It's a very straightforward document, and it explains the
Referer (sic) mechanism.