Detecting HTTPS connection through WL4.5 NSAPI plugin?

Question

ello,
I've looked around the newsgroups and on the support site for
similar threads but I haven't found any that have asked this question
yet.
We have a weblogic 4.5 instance listening for requests on 8000 via
the NSAPI plugin and Netscape Enterprise Server. NES is handing off all
requests for JSP pages to the WL plugin.NES's http port is 80, and for
https, 443. In both cases, traffic gets directed to WL port 8000 (in raw
text). I've got all that under control.
The problem is that for some of the JSP's that are "secure", we want
to require that certain pages only be accessible via https. But I
haven't found a satisfactory way of doing that yet, because due to the
NSAPI plugin everything comes to WL with URL's starting with "http"....
The best that I can come up with to detect differences between
whether a connection is secure is that a few request headers show
slightly different info. But I'm not sure if these differences are
consistent and reproducible, or just due to my development setup.
Note: My development setup is the same as described above except
NES' http port is 7080.
request.getHeader("host"): HTTP: "wintermute:7080" HTTPS:
"wintermute"
request.getServerPort(): HTTP: "7080" HTTPS: "8000".
Everything else that I've queried for shows either identical or
non-existent values, e.g.,
request.getScheme() : "http" (for both HTTP and HTTPS)
request.getAuthType() : "" <nothing>
The Sun J2EE spec says that HttpServletRequest also has an
"isSecure()" method but it doesn't exist on my setup...
Will these differences hold up consistently (I assume the NSAPI
plugin is rewriting some headers)? Is there a better way to do this?
Any and all help is greatly appreciated.
Jack Lin

Answer 1

From the very little I know about NSAPI you can doctor the incomming url
prior to forwarding it to WLAS. One solution would be to prefix the url
with /secured/ so that wlas can determine that the page is sucure based on
the incomming request URI. I will be playing with the soon and let you know
how I go :)
Cheers
Rob
"Jack Lin" <[email protected]> wrote in message
news:[email protected]...
So is there a way I can do this in 4.51?
Jack
Cameron Purdy wrote:
Hmm ... I did not realize you were not on 5.1 ... sorry.
Cameron Purdy
"Jack Lin" <[email protected]> wrote in message
news:[email protected]...
Thanks for the response.
Actually I did try that based on the Sun Servlet API specs, but
for
whatever reason, that method doesn't appear to exist inHttpServletRequest.
This is the error I get.
Method isSecure() not found in interface
javax.servlet.http.HttpServletRequest.
out.print(weblogic.utils.StringUtils.valueOf(request.isSecure()
)); //[ jsp/unit_test/headers.jsp; Line: 24]
^
Just to make sure I wasn't doing something really stupid, I did.
Class foo = request.getClass();
And after stripping out the set...() functions and extra method
signature
junk
I saw only this list of methods.
getRequestURI()
getServletPath()
getPathInfo()
getPathTranslated()
getAttribute(java.lang.String )
getAttributeNames()
getQueryString()
getProtocol()
getServerName()
getServerPort()
getRemoteUser()
getRemoteAddr()
getRemoteHost()
getAuthType()
getHeader(java.lang.String)
getIntHeader(java.lang.String,int)
getIntHeader(java.lang.String)
getDateHeader(java.lang.String,long)
getDateHeader(java.lang.String)
getHeaderName(int)
getHeader(int)
getHeaderNames()
getRealPath(java.lang.String)
getInputStream()
getCharacterEncoding()
getScheme()
getCookies()
getSession()
getSession(boolean)
getRequestedSessionId()
isRequestedSessionIdFromCookie()
isRequestedSessionIdFromURL()
isRequestedSessionIdFromUrl()
isRequestedSessionIdValid()
I'm just assuming that the Sun specs are kind of pie-in-the-sky,
this-is-how-it-should-be guidelines.... either that or Weblogic is
doing
something funky with the request object? We're using JDK1.2.1_03.
There is an additional clarification to the message I posted. Tosee
those
two differences in getServerPort() and getHeader("host"), I hit the
two
urls:
http://wintermute:7080/headers.jsp
https://wintermute/headers.jsp
So, duh, of course i makes sense that the two methods returneddifferent
information. Once I replaced the https url with
https://wintermute:443/headers.jsp
I was left with identical information.
So now the only solution I can think of (kind of ugly, but not a
big
deal)
is that I "identify" secure connections on the production environment
by
having http URLs w/out a port, and then having the https URLs includethe
ssl
port. I think it will work consistently.... but I'd love to be able tohide
that :443....
Jack
Cameron Purdy wrote:
Have you tried request.isSecure()? That is what I would try first,
but
I
would give it 50/50 odds based on the information you have provided.
Cameron Purdy
"Jack Lin" <[email protected]> wrote in message
news:[email protected]...
ello,
I've looked around the newsgroups and on the support site for
similar threads but I haven't found any that have asked this
question
yet.
We have a weblogic 4.5 instance listening for requests on 8000via
the NSAPI plugin and Netscape Enterprise Server. NES is handingoff
all
requests for JSP pages to the WL plugin.NES's http port is 80, and
for
https, 443. In both cases, traffic gets directed to WL port 8000(in
raw
text). I've got all that under control.
The problem is that for some of the JSP's that are "secure",
we
want
to require that certain pages only be accessible via https. But I
haven't found a satisfactory way of doing that yet, because due to
the
NSAPI plugin everything comes to WL with URL's starting with"http"....
The best that I can come up with to detect differences between
whether a connection is secure is that a few request headers show
slightly different info. But I'm not sure if these differences are
consistent and reproducible, or just due to my development setup.
Note: My development setup is the same as described above
except
NES' http port is 7080.
request.getHeader("host"): HTTP: "wintermute:7080" HTTPS:
"wintermute"
request.getServerPort(): HTTP: "7080" HTTPS: "8000".
Everything else that I've queried for shows either identicalor
non-existent values, e.g.,
request.getScheme() : "http" (for both HTTP and HTTPS)
request.getAuthType() : "" <nothing>
The Sun J2EE spec says that HttpServletRequest also has an
"isSecure()" method but it doesn't exist on my setup...
Will these differences hold up consistently (I assume theNSAPI
plugin is rewriting some headers)? Is there a better way to dothis?
Any and all help is greatly appreciated.
Jack Lin