Re: Can't get ssl redirection to work properly

[Terence M. Bandoian]

Hi,

You might try including a URL pattern containing only / in addition to
the /* pattern.

-Terence M. Bandoian


 Hi again.. I don´t know if this mail reached the mailinglist som I
 just reply to myself to get the attention again ;).
 Is this kind of behaviour by tomcat normal with the redirection?. Does
 behave in this way even if you just have an application.war file
 deployed on a standalone tomcat?

 Best regards
 Stefan Nilsson.
 On 7/15/05, Stefan Nilsson [EMAIL PROTECTED] wrote:
  

 I am running Jboss 4.0.1 with the tomcat 5.0 and I have an
 application.ear called pds running on it. To access the application
 you simple write http://adress:8080/pds;

 Now I wanted to enable ssl on the webapp.war in the application so I
 changed the server.xml and web.xml and created a keystore and
 everything. I redirect from 8080 to 8443 and everything works as
 long as do like this.
 https://adress:8443/pds - works!!

 http://adress:8080/pds/login.jsp - works! get redirected to
 https://adress:8443/pds/x

 http://adress:8080/pds - doesn´t work - I time out and get a no page
 found error.

 I really need the the old url http://adress:8080/pds; to be
 redirected to https://adress:8443/pds 

 Any suggestions??
 Best regards
 Stefan Nisson

 Below follows some relevant sections from my server.xml and web.xml:

 === server.xml ==

   Connector
   port = 8080
   address = ${jboss.bind.address}
   maxThreads = 150
   minSpareThreads = 25
   maxSpareThreads = 75
   enableLookups = false
   redirectPort = 8443
   acceptCount = 100
   connectionTimeout = 2
   disableUploadTimeout = true/

   Connector
   port = 8443
   address = ${jboss.bind.address}
   maxThreads = 100
   minSpareThreads = 5
   maxSpareThreads = 15
   scheme = https
   secure = true
   clientAuth = false
   keystoreFile = ./keystore
   keystorePass = secret
   sslProtocol = TLS/


 === web.xml =
 security-constraint
   display-nameSecurity for Julius PDS/display-name
   web-resource-collection
   web-resource-nameJulius web Security/web-resource-name
   descriptionRedirect all to SSL/description
   url-pattern/*/url-pattern
   /web-resource-collection
   user-data-constraint
   descriptionProtection should be CONFIDENTIAL/description
   transport-guaranteeCONFIDENTIAL/transport-guarantee
   /user-data-constraint
   /security-constraint



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Can't get ssl redirection to work properly

[beetle]

Dear sir,
Thankyou very much for update ,regards,Gregory
- Original Message - 
From: Terence M. Bandoian [EMAIL PROTECTED]

To: tomcat-user@jakarta.apache.org
Sent: Saturday, July 23, 2005 7:19 AM
Subject: Re: Can't get ssl redirection to work properly



Hi,

You might try including a URL pattern containing only / in addition to
the /* pattern.

-Terence M. Bandoian



Hi again.. I don´t know if this mail reached the mailinglist som I
just reply to myself to get the attention again ;).
Is this kind of behaviour by tomcat normal with the redirection?. Does
behave in this way even if you just have an application.war file
deployed on a standalone tomcat?

Best regards
Stefan Nilsson.
On 7/15/05, Stefan Nilsson [EMAIL PROTECTED] wrote:



I am running Jboss 4.0.1 with the tomcat 5.0 and I have an
application.ear called pds running on it. To access the application
you simple write http://adress:8080/pds;

Now I wanted to enable ssl on the webapp.war in the application so I
changed the server.xml and web.xml and created a keystore and
everything. I redirect from 8080 to 8443 and everything works as
long as do like this.
https://adress:8443/pds - works!!

http://adress:8080/pds/login.jsp - works! get redirected to
https://adress:8443/pds/x

http://adress:8080/pds - doesn´t work - I time out and get a no page
found error.

I really need the the old url http://adress:8080/pds; to be
redirected to https://adress:8443/pds 

Any suggestions??
Best regards
Stefan Nisson

Below follows some relevant sections from my server.xml and web.xml:

=== server.xml ==

  Connector
  port = 8080
  address = ${jboss.bind.address}
  maxThreads = 150
  minSpareThreads = 25
  maxSpareThreads = 75
  enableLookups = false
  redirectPort = 8443
  acceptCount = 100
  connectionTimeout = 2
  disableUploadTimeout = true/

  Connector
  port = 8443
  address = ${jboss.bind.address}
  maxThreads = 100
  minSpareThreads = 5
  maxSpareThreads = 15
  scheme = https
  secure = true
  clientAuth = false
  keystoreFile = ./keystore
  keystorePass = secret
  sslProtocol = TLS/


=== web.xml =
security-constraint
  display-nameSecurity for Julius PDS/display-name
  web-resource-collection
  web-resource-nameJulius web Security/web-resource-name
  descriptionRedirect all to SSL/description
  url-pattern/*/url-pattern
  /web-resource-collection
  user-data-constraint
  descriptionProtection should be CONFIDENTIAL/description
  transport-guaranteeCONFIDENTIAL/transport-guarantee
  /user-data-constraint
  /security-constraint





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Can't get ssl redirection to work properly

[Stefan Nilsson]

Hi again.. I don´t know if this mail reached the mailinglist som I
just reply to myself to get the attention again ;).
Is this kind of behaviour by tomcat normal with the redirection?. Does
behave in this way even if you just have an application.war file
deployed on a standalone tomcat?

Best regards
Stefan Nilsson. 

On 7/15/05, Stefan Nilsson [EMAIL PROTECTED] wrote:
 I am running Jboss 4.0.1 with the tomcat 5.0 and I have an
 application.ear called pds running on it. To access the application
 you simple write http://adress:8080/pds;
 
 Now I wanted to enable ssl on the webapp.war in the application so I
 changed the server.xml and web.xml and created a keystore and
 everything. I redirect from 8080 to 8443 and everything works as
 long as do like this.
 https://adress:8443/pds - works!!
 
 http://adress:8080/pds/login.jsp - works! get redirected to
 https://adress:8443/pds/x
 
 http://adress:8080/pds - doesn´t work - I time out and get a no page
 found error.
 
 I really need the the old url http://adress:8080/pds; to be
 redirected to https://adress:8443/pds 
 
 Any suggestions??
 Best regards
 Stefan Nisson
 
 Below follows some relevant sections from my server.xml and web.xml:
 
 === server.xml ==
 
Connector
port = 8080
address = ${jboss.bind.address}
maxThreads = 150
minSpareThreads = 25
maxSpareThreads = 75
enableLookups = false
redirectPort = 8443
acceptCount = 100
connectionTimeout = 2
disableUploadTimeout = true/
 
Connector
port = 8443
address = ${jboss.bind.address}
maxThreads = 100
minSpareThreads = 5
maxSpareThreads = 15
scheme = https
secure = true
clientAuth = false
keystoreFile = ./keystore
keystorePass = secret
sslProtocol = TLS/
 
 
 === web.xml =
 security-constraint
display-nameSecurity for Julius PDS/display-name
web-resource-collection
web-resource-nameJulius web Security/web-resource-name
descriptionRedirect all to SSL/description
url-pattern/*/url-pattern
/web-resource-collection
user-data-constraint
descriptionProtection should be CONFIDENTIAL/description
transport-guaranteeCONFIDENTIAL/transport-guarantee
/user-data-constraint
/security-constraint


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Can't get ssl redirection to work properly

[Manfred Steurer]

I think you have a problem with the url-pattern in the web.xml.
It redirects anything after pds/ to ssl - but in http://adress:8080/pds 
there is nothing.


I don't have time to test now, but it may work without any url-pattern 
or just * instead of /*.


- ms

Stefan Nilsson wrote:


Hi again.. I don´t know if this mail reached the mailinglist som I
just reply to myself to get the attention again ;).
Is this kind of behaviour by tomcat normal with the redirection?. Does
behave in this way even if you just have an application.war file
deployed on a standalone tomcat?

Best regards
Stefan Nilsson. 


On 7/15/05, Stefan Nilsson [EMAIL PROTECTED] wrote:
 


I am running Jboss 4.0.1 with the tomcat 5.0 and I have an
application.ear called pds running on it. To access the application
you simple write http://adress:8080/pds;

Now I wanted to enable ssl on the webapp.war in the application so I
changed the server.xml and web.xml and created a keystore and
everything. I redirect from 8080 to 8443 and everything works as
long as do like this.
https://adress:8443/pds - works!!

http://adress:8080/pds/login.jsp - works! get redirected to
https://adress:8443/pds/x

http://adress:8080/pds - doesn´t work - I time out and get a no page
found error.

I really need the the old url http://adress:8080/pds; to be
redirected to https://adress:8443/pds 

Any suggestions??
Best regards
Stefan Nisson

Below follows some relevant sections from my server.xml and web.xml:

=== server.xml ==

  Connector
  port = 8080
  address = ${jboss.bind.address}
  maxThreads = 150
  minSpareThreads = 25
  maxSpareThreads = 75
  enableLookups = false
  redirectPort = 8443
  acceptCount = 100
  connectionTimeout = 2
  disableUploadTimeout = true/

  Connector
  port = 8443
  address = ${jboss.bind.address}
  maxThreads = 100
  minSpareThreads = 5
  maxSpareThreads = 15
  scheme = https
  secure = true
  clientAuth = false
  keystoreFile = ./keystore
  keystorePass = secret
  sslProtocol = TLS/


=== web.xml =
security-constraint
  display-nameSecurity for Julius PDS/display-name
  web-resource-collection
  web-resource-nameJulius web Security/web-resource-name
  descriptionRedirect all to SSL/description
  url-pattern/*/url-pattern
  /web-resource-collection
  user-data-constraint
  descriptionProtection should be CONFIDENTIAL/description
  transport-guaranteeCONFIDENTIAL/transport-guarantee
  /user-data-constraint
  /security-constraint

   



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Can't get ssl redirection to work properly

[Terence M. Bandoian]

Hi,

You might try including a URL pattern containing only / in addition to
the /* pattern.

-Terence M. Bandoian


 Hi again.. I don´t know if this mail reached the mailinglist som I
 just reply to myself to get the attention again ;).
 Is this kind of behaviour by tomcat normal with the redirection?. Does
 behave in this way even if you just have an application.war file
 deployed on a standalone tomcat?

 Best regards
 Stefan Nilsson.
 On 7/15/05, Stefan Nilsson [EMAIL PROTECTED] wrote:
  

 I am running Jboss 4.0.1 with the tomcat 5.0 and I have an
 application.ear called pds running on it. To access the application
 you simple write http://adress:8080/pds;

 Now I wanted to enable ssl on the webapp.war in the application so I
 changed the server.xml and web.xml and created a keystore and
 everything. I redirect from 8080 to 8443 and everything works as
 long as do like this.
 https://adress:8443/pds - works!!

 http://adress:8080/pds/login.jsp - works! get redirected to
 https://adress:8443/pds/x

 http://adress:8080/pds - doesn´t work - I time out and get a no page
 found error.

 I really need the the old url http://adress:8080/pds; to be
 redirected to https://adress:8443/pds 

 Any suggestions??
 Best regards
 Stefan Nisson

 Below follows some relevant sections from my server.xml and web.xml:

 === server.xml ==

   Connector
   port = 8080
   address = ${jboss.bind.address}
   maxThreads = 150
   minSpareThreads = 25
   maxSpareThreads = 75
   enableLookups = false
   redirectPort = 8443
   acceptCount = 100
   connectionTimeout = 2
   disableUploadTimeout = true/

   Connector
   port = 8443
   address = ${jboss.bind.address}
   maxThreads = 100
   minSpareThreads = 5
   maxSpareThreads = 15
   scheme = https
   secure = true
   clientAuth = false
   keystoreFile = ./keystore
   keystorePass = secret
   sslProtocol = TLS/


 === web.xml =
 security-constraint
   display-nameSecurity for Julius PDS/display-name
   web-resource-collection
   web-resource-nameJulius web Security/web-resource-name
   descriptionRedirect all to SSL/description
   url-pattern/*/url-pattern
   /web-resource-collection
   user-data-constraint
   descriptionProtection should be CONFIDENTIAL/description
   transport-guaranteeCONFIDENTIAL/transport-guarantee
   /user-data-constraint
   /security-constraint


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Can't get ssl redirection to work properly

[beetle]

DEAR  SIR
Thankyou for your mail, best regards Gregory
- Original Message - 
From: Terence M. Bandoian [EMAIL PROTECTED]

To: tomcat-user@jakarta.apache.org
Sent: Friday, July 22, 2005 9:52 PM
Subject: Re: Can't get ssl redirection to work properly



Hi,

You might try including a URL pattern containing only / in addition to
the /* pattern.

-Terence M. Bandoian



Hi again.. I don´t know if this mail reached the mailinglist som I
just reply to myself to get the attention again ;).
Is this kind of behaviour by tomcat normal with the redirection?. Does
behave in this way even if you just have an application.war file
deployed on a standalone tomcat?

Best regards
Stefan Nilsson.
On 7/15/05, Stefan Nilsson [EMAIL PROTECTED] wrote:



I am running Jboss 4.0.1 with the tomcat 5.0 and I have an
application.ear called pds running on it. To access the application
you simple write http://adress:8080/pds;

Now I wanted to enable ssl on the webapp.war in the application so I
changed the server.xml and web.xml and created a keystore and
everything. I redirect from 8080 to 8443 and everything works as
long as do like this.
https://adress:8443/pds - works!!

http://adress:8080/pds/login.jsp - works! get redirected to
https://adress:8443/pds/x

http://adress:8080/pds - doesn´t work - I time out and get a no page
found error.

I really need the the old url http://adress:8080/pds; to be
redirected to https://adress:8443/pds 

Any suggestions??
Best regards
Stefan Nisson

Below follows some relevant sections from my server.xml and web.xml:

=== server.xml ==

  Connector
  port = 8080
  address = ${jboss.bind.address}
  maxThreads = 150
  minSpareThreads = 25
  maxSpareThreads = 75
  enableLookups = false
  redirectPort = 8443
  acceptCount = 100
  connectionTimeout = 2
  disableUploadTimeout = true/

  Connector
  port = 8443
  address = ${jboss.bind.address}
  maxThreads = 100
  minSpareThreads = 5
  maxSpareThreads = 15
  scheme = https
  secure = true
  clientAuth = false
  keystoreFile = ./keystore
  keystorePass = secret
  sslProtocol = TLS/


=== web.xml =
security-constraint
  display-nameSecurity for Julius PDS/display-name
  web-resource-collection
  web-resource-nameJulius web Security/web-resource-name
  descriptionRedirect all to SSL/description
  url-pattern/*/url-pattern
  /web-resource-collection
  user-data-constraint
  descriptionProtection should be CONFIDENTIAL/description
  transport-guaranteeCONFIDENTIAL/transport-guarantee
  /user-data-constraint
  /security-constraint




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Can't get ssl redirection to work properly

[Stefan Nilsson]

I am running Jboss 4.0.1 with the tomcat 5.0 and I have an
application.ear called pds running on it. To access the application
you simple write http://adress:8080/pds;

Now I wanted to enable ssl on the webapp.war in the application so I
changed the server.xml and web.xml and created a keystore and
everything. I redirect from 8080 to 8443 and everything works as
long as do like this.
https://adress:8443/pds - works!! 

http://adress:8080/pds/login.jsp - works! get redirected to
https://adress:8443/pds/x

http://adress:8080/pds - doesn´t work - I time out and get a no page
found error.

I really need the the old url http://adress:8080/pds; to be
redirected to https://adress:8443/pds 

Any suggestions?? 
Best regards
Stefan Nisson

Below follows some relevant sections from my server.xml and web.xml: 

=== server.xml ==

Connector
port = 8080
address = ${jboss.bind.address}
maxThreads = 150
minSpareThreads = 25
maxSpareThreads = 75
enableLookups = false
redirectPort = 8443
acceptCount = 100
connectionTimeout = 2
disableUploadTimeout = true/
   
Connector
port = 8443
address = ${jboss.bind.address}
maxThreads = 100
minSpareThreads = 5
maxSpareThreads = 15
scheme = https
secure = true
clientAuth = false
keystoreFile = ./keystore
keystorePass = secret
sslProtocol = TLS/


=== web.xml =
security-constraint
display-nameSecurity for Julius PDS/display-name
web-resource-collection
web-resource-nameJulius web Security/web-resource-name
descriptionRedirect all to SSL/description
url-pattern/*/url-pattern
/web-resource-collection
user-data-constraint
descriptionProtection should be CONFIDENTIAL/description
transport-guaranteeCONFIDENTIAL/transport-guarantee
/user-data-constraint
/security-constraint

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Redirection/Multiple URLs (UNCLASSIFIED)

[Samara, Fadi N Mr ACSIM/ASPEX]

Classification:  UNCLASSIFIED 
Caveats: NONE

Hey everyone,

I am trying to let 2 URLs to resolve to the same IP address.  I am using
apache as a web server that talks to the application server where the app is
deployed.  What is the best way to approach this ? Would a redirect tag do
it ?  Where (in which file) does the change have to be made ?

Thanks a lot for your support.

Fadi
Classification:  UNCLASSIFIED 
Caveats: NONE


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Problem with redirection for Tomcat Basic Authentication

[Javier Santos Martin-Moreno]

Hello,

I am running Tomcat 5.5.9 on Windows 2000. I configured the ISAPI
redirector (version 1.2.12) so that Tomcat worked along with IIS and
everything seemed to work fine, but...

I have a Tomcat application which requires basic authentication. Everything
works fine if I access from http://localhost:8080/mywebapp/, I get
authenticated and can navigate, so I think the realm is configured
correctly. But if I try to access from http://localhost/mywebapp/ (the path
to my app is added to uriworkermap.properties) I get a Windows
authentication prompt window ('Enter network password' with fields to
introduce username, password plus domain) instead of Tomcat's basic
authentication prompt window. However, once I login (using
http://localhost:8080/mywebapp/) I can navigate without problems through
the application pages without using the ':8080' part. So it seems like
redirection works except for the authentication part.

Does anyone have any ideas so that I can login to my application from
without the need to specify the port?

Thanks in advance,

Javier Santos


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Problem with redirection for Tomcat Basic Authentication

[Mark Thomas]

I suspect the IE and IIS are conspiring to use Windows Native
Authentication. I think this is a browser setting where IE tries this by
default if talking to IIS.

The settings should be under something like:
IE  Tools  Internet options  security  custom level  user
authentication

I can't remember what setting you need to use but try the various
options and see what happens.

Mark

Javier Santos Martin-Moreno wrote:

Hello,

I am running Tomcat 5.5.9 on Windows 2000. I configured the ISAPI
redirector (version 1.2.12) so that Tomcat worked along with IIS and
everything seemed to work fine, but...

I have a Tomcat application which requires basic authentication. Everything
works fine if I access from http://localhost:8080/mywebapp/, I get
authenticated and can navigate, so I think the realm is configured
correctly. But if I try to access from http://localhost/mywebapp/ (the path
to my app is added to uriworkermap.properties) I get a Windows
authentication prompt window ('Enter network password' with fields to
introduce username, password plus domain) instead of Tomcat's basic
authentication prompt window. However, once I login (using
http://localhost:8080/mywebapp/) I can navigate without problems through
the application pages without using the ':8080' part. So it seems like
redirection works except for the authentication part.

Does anyone have any ideas so that I can login to my application from
without the need to specify the port?

Thanks in advance,

Javier Santos


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

404 redirection question

[Wade Billings]

I have the need to redirect visitors to my site to different error pages
depending on the type of element missing. For example, if the element
that is missing is an image file (e.g. *.jpg, *.gif), then I want to
present them with a custom 404 error page. If the missing element is an
entire page, then I want to present them with a completely different 404
error page.
 
I know that I can set Tomcat to catch the 404 errors and present a
custom page, but what I need to know is can I get as granular as I need
to get using the configuration, or do I have to put this in an jsp file
and solve it programmatically?
 
Thanks,
 
Q. Wade Billings
Manager, Operations / Sr. Unix Administrator
RHCE, CNA, CCNA, CNS
Operations and Technology Group
 
email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 
phone: (310) 998-6364
toll free: (800) 648-5049
fax: (310) 998-6999
cell: (661) 210-5593
snailmail: 2401 Colorado #200 Santa Monica , CA 90404
http: www.lowermybills.com http://www.lowermybills.com/ 
 
Fall seven time. stand up eight.
- Japanese Proverb
 
Never attribute to malice that which can be adequately
explained by stupidity.
- Hanlon's Razor
 
I think we consider too much the good luck of the early bird, and not
enough the bad luck of the early worm.

- FDR

 

RE: 404 redirection question

[Fritz Schneider]

Wade,

Browsers don't display the error page for missing GIF or JPEG elements in a
page, only when the entire requested URL gets a 404. If you have hyperlinks
to images, as opposed to HTML pages with images embedded, then what you are
looking for can be accomplished. You could create a JSP which does the
following to get the original URI:
// If this is an error page, get the original URI
String missingURI = (String) req.getAttribute(
javax.servlet.forward.request_uri);
if (missingURI == null) missingURI =req.getRequestURI();

Fritz

-Original Message-
From: Wade Billings [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, May 18, 2005 8:10 AM
To: tomcat-user@jakarta.apache.org
Subject: ***SPAM*** 404 redirection question

I have the need to redirect visitors to my site to different error pages
depending on the type of element missing. For example, if the element
that is missing is an image file (e.g. *.jpg, *.gif), then I want to
present them with a custom 404 error page. If the missing element is an
entire page, then I want to present them with a completely different 404
error page.
 
I know that I can set Tomcat to catch the 404 errors and present a
custom page, but what I need to know is can I get as granular as I need
to get using the configuration, or do I have to put this in an jsp file
and solve it programmatically?
 
Thanks,
 
Q. Wade Billings
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: 404 redirection question

[David Wall]

Fritz Schneider wrote:
If you have hyperlinks
to images, as opposed to HTML pages with images embedded,
How would you embed images inside the HTML rather than using hyperlinks 
to the image?

David
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: 404 redirection question

[Fritz Schneider]

By having a page that is essentially:
htmlhead/body
  img src=images/xxx.jpg/
/body/html

-Original Message-
From: David Wall [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, May 18, 2005 11:01 AM
To: Tomcat Users List
Subject: Re: 404 redirection question


Fritz Schneider wrote:

If you have hyperlinks
to images, as opposed to HTML pages with images embedded,

How would you embed images inside the HTML rather than using hyperlinks 
to the image?

David

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: 404 redirection question

[David Wall]

Fritz,
Well, that's a hyperlink to the image, not embedded.  In the case below, 
the image is not embedded in the HTML but is simply a link to the image 
that requires an HTTP(S) GET to retrieve.  With a relative URL like you 
used, it just constructs the complete URL by appending the current 
page's URL to the front, so images/xxx.jpg becomes something like 
http(s)://www.host.com/app/images/xxx.jpg assuming the HTML is located 
at http(s)://www.host.com/app.

David
Fritz Schneider wrote:
By having a page that is essentially:
htmlhead/body
 img src=images/xxx.jpg/
/body/html

Fritz Schneider wrote:
 

If you have hyperlinks
to images, as opposed to HTML pages with images embedded,
   

How would you embed images inside the HTML rather than using hyperlinks 
to the image?

David
 

RE: 404 redirection question

[Fritz Schneider]

David,

I'm differentiating between a link as in src= and a hyperlink as in href=.
For a link, the browser does indeed do another HTTP GET to retrieve it, but
if the result is a 404, the rest of the response is discarded and the image
is rendered as a small box with a red x in it.

On the other hand, if the image was the target of a hyperlink and it got a
404, the error page would be displayed (unless the IE friendly option were
selected). Example: http://peacham.homeip.net/notthere.jpg.

Fritz

-Original Message-
From: David Wall [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, May 18, 2005 2:11 PM
To: Tomcat Users List
Subject: Re: 404 redirection question

Fritz,

Well, that's a hyperlink to the image, not embedded.  In the case below, 
the image is not embedded in the HTML but is simply a link to the image 
that requires an HTTP(S) GET to retrieve.  With a relative URL like you 
used, it just constructs the complete URL by appending the current 
page's URL to the front, so images/xxx.jpg becomes something like 
http(s)://www.host.com/app/images/xxx.jpg assuming the HTML is located 
at http(s)://www.host.com/app.

David


Fritz Schneider wrote:

By having a page that is essentially:
htmlhead/body
  img src=images/xxx.jpg/
/body/html



Fritz Schneider wrote:
  

If you have hyperlinks
to images, as opposed to HTML pages with images embedded,



How would you embed images inside the HTML rather than using hyperlinks 
to the image?

David
  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Error Redirection

[Steve Vanspall]

Hi there,

This is probably an obvious question, but if a JSP or some other error occurs 
that would usually make tomcat do a printStackTrace() into HTML and display it 
on the browser. 

e.g

--

HTTP Status 500 -




type Exception report

message

description The server encountered an internal error () that prevented it
from fulfilling this request.

exception

java.lang.NullPointerException
at com.crm.web.form.EditSupplierForm.validate(EditSupplierForm.java:46)
at
org.apache.struts.action.RequestProcessor.processValidate(RequestProcessor.j
ava:912)
at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:255)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1422)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:523)
at javax.servlet.http.HttpServlet.service(HttpServlet.java)
at javax.servlet.http.HttpServlet.service(HttpServlet.java)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Unknown
Source)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(Unknown Source)
at org.apache.catalina.core.StandardWrapperValve.invoke(Unknown Source)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(Unknown Source)
at org.apache.catalina.core.StandardPipeline.invoke(Unknown Source)
at org.apache.catalina.core.ContainerBase.invoke(Unknown Source)
at org.apache.catalina.core.StandardContextValve.invoke(Unknown Source)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(Unknown Source)
at org.apache.catalina.core.StandardPipeline.invoke(Unknown Source)
at org.apache.catalina.core.ContainerBase.invoke(Unknown Source)
at org.apache.catalina.core.StandardContext.invoke(Unknown Source)
at org.apache.catalina.core.StandardHostValve.invoke(Unknown Source)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(Unknown Source)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(Unknown Source)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(Unknown Source)
at org.apache.catalina.valves.ErrorReportValve.invoke(Unknown Source)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(Unknown Source)
at org.apache.catalina.core.StandardPipeline.invoke(Unknown Source)
at org.apache.catalina.core.ContainerBase.invoke(Unknown Source)
at org.apache.catalina.core.StandardEngineValve.invoke(Unknown Source)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(Unknown Source)
at org.apache.catalina.core.StandardPipeline.invoke(Unknown Source)
at org.apache.catalina.core.ContainerBase.invoke(Unknown Source)
at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:594)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne
ction(Http11Protocol.java:392)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java(Compil
ed Code))
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
a:619)
at java.lang.Thread.run(Thread.java:568)

---


is there a way to make it forward to a clean error page when on a production 
system?

Regards

Steve

RE: Error Redirection

[Fritz Schneider]

Steve,

Have you tried a custom error page for error 500?

error-page
  error-code500/error-code
  location/_error/500.html/location
/error-page

Fritz
-Original Message-
From: Steve Vanspall [mailto:[EMAIL PROTECTED] 
Sent: Sunday, May 01, 2005 6:33 PM
To: Tomcat User List
Subject: Error Redirection

Hi there,

This is probably an obvious question, but if a JSP or some other error
occurs that would usually make tomcat do a printStackTrace() into HTML and
display it on the browser. 

[snip...]

is there a way to make it forward to a clean error page when on a production
system?

Regards

Steve


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Error Redirection

[Steve Vanspall]

oh ok thanks,

new it would be simple

oh but is there a default, catch all option, actually i will look the tag
up.

Thanks

Steve
- Original Message -
From: Fritz Schneider [EMAIL PROTECTED]
To: 'Tomcat Users List' tomcat-user@jakarta.apache.org
Sent: Monday, May 02, 2005 11:44 AM
Subject: RE: Error Redirection



 Steve,

 Have you tried a custom error page for error 500?

 error-page
   error-code500/error-code
   location/_error/500.html/location
 /error-page

 Fritz
 -Original Message-
 From: Steve Vanspall [mailto:[EMAIL PROTECTED]
 Sent: Sunday, May 01, 2005 6:33 PM
 To: Tomcat User List
 Subject: Error Redirection

 Hi there,

 This is probably an obvious question, but if a JSP or some other error
 occurs that would usually make tomcat do a printStackTrace() into HTML and
 display it on the browser.

 [snip...]

 is there a way to make it forward to a clean error page when on a
production
 system?

 Regards

 Steve


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Enquiry about IIS-TOMCAT redirection

[Stephen . Chin]

Hi,

In implementing the change, is it possible to exclude some pages (i.e. JSP)
not to route to IIS
and route it to tomcat?

Many thanks

-
This transmission and the information it contains including any attachment,
is confidential and may be subject to legal privilege. If you are not the
intended recipient, you must not peruse, use, disseminate, disclose or copy
this transmission. If you have received this transmission (or any copy) in
error, please notify us immediately by reply e-mail to
[EMAIL PROTECTED] Please delete the original transmission
(including any attachment) and its contents and destroy or return to us any
hard copy.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Enquiry about IIS-TOMCAT redirection

[Parsons Technical Services]

http://jakarta.apache.org/tomcat/connectors-doc/howto/iis.html
Doug
- Original Message - 
From: [EMAIL PROTECTED]
To: tomcat-user@jakarta.apache.org
Sent: Thursday, January 06, 2005 9:57 PM
Subject: Enquiry about IIS-TOMCAT redirection


Hi,
In implementing the change, is it possible to exclude some pages (i.e. 
JSP)
not to route to IIS
and route it to tomcat?

Many thanks
-
This transmission and the information it contains including any 
attachment,
is confidential and may be subject to legal privilege. If you are not the
intended recipient, you must not peruse, use, disseminate, disclose or 
copy
this transmission. If you have received this transmission (or any copy) in
error, please notify us immediately by reply e-mail to
[EMAIL PROTECTED] Please delete the original transmission
(including any attachment) and its contents and destroy or return to us 
any
hard copy.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Location: redirection

[Lisa Soto]

Hi, 

We're using perl within tomcat 4.1.27. The perl scripts run all right,
but the redirections don't work at all. 

If I run the script on the command line, it returns a proper Location:
directive, but it doesn't seem to show up in the web browser and/or
affect its reaction. 

Any ideas? 

Thanks,
Lisa 
-- 
Lisa Soto
[EMAIL PROTECTED]
(631) 344-2009
Systems Administrator
ITD Unix Services


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Location: redirection

[Phillip Qin]

Please refer to my previous post regarding hack into the CGIServlet.

-Original Message-
From: Lisa Soto [mailto:[EMAIL PROTECTED] 
Sent: November 15, 2004 3:24 PM
To: [EMAIL PROTECTED]
Subject: Location: redirection


Hi, 

We're using perl within tomcat 4.1.27. The perl scripts run all right, but
the redirections don't work at all. 

If I run the script on the command line, it returns a proper Location:
directive, but it doesn't seem to show up in the web browser and/or affect
its reaction. 

Any ideas? 

Thanks,
Lisa 
-- 
Lisa Soto
[EMAIL PROTECTED]
(631) 344-2009
Systems Administrator
ITD Unix Services


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


!DSPAM:4199105e51622011559358!

RE: Location: redirection

[Shapira, Yoav]

Hi,

We're using perl within tomcat 4.1.27. The perl scripts run all right,
but the redirections don't work at all.

Using an external mechanism (such as a CGI perl scripts in your case)
for redirection in Tomcat is tricky at best, and doomed to failure at
worst.  The reason is that the script is not really part of the servlet
request/response pipeline.  Rather, it is invoked as an exec by a Tomcat
servlet (in your case, the CGI servlet that ships with Tomcat, I
assume).

That servlet can easily do a response redirect or request forward, but
the script cannot.

Accordingly, if you stick with the script at all, modify it to return
the redirection URL, and have the servlet (a custom extension to the CGI
Servlet that ships with Tomcat probably) read and act upon this URL by
doing the redirection.

Yoav



This e-mail, including any attachments, is a confidential business 
communication, and may contain information that is confidential, proprietary 
and/or privileged.  This e-mail is intended only for the individual(s) to whom 
it is addressed, and may not be saved, copied, printed, disclosed or used by 
anyone else.  If you are not the(an) intended recipient, please immediately 
delete this e-mail from your computer system and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Location: redirection

[Phillip Qin]

The redirect has to be done in inner class CGIRunner of servlet CGIServlet.
Tomcat 4.1.30/5.0.28 do not handle redirect. You have to modify method run,
in while (isRunning) add your own handling. Our cgi scripts have Status
302 for redirection, so I added header check below

if (line.startsWith(HTTP)) {
//TODO: should set status codes (NPH support)
/*
 * response.setStatus(getStatusCode(line));
 */
} else if (line.indexOf(:) = 0) {
String header =
line.substring(0, line.indexOf(:)).trim();
String value =
line.substring(line.indexOf(:) +
1).trim(); 
// PQ: quick fix for 302 redirect
if
(header.trim().compareToIgnoreCase(STATUS)==0  line.indexOf(302)-1) {
log(runCGI(my): status code=302);
response.setStatus(302);
} else {
response.addHeader(header , value);
if
((header.toLowerCase().equals(content-type))

(!value.toLowerCase().startsWith(text))) {
isBinaryContent = true;
}
}
} else {
log(runCGI: bad header line \ + line + \);
}

I know it's ugly.


-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED] 
Sent: November 15, 2004 3:31 PM
To: Tomcat Users List
Subject: RE: Location: redirection



Hi,

We're using perl within tomcat 4.1.27. The perl scripts run all right, 
but the redirections don't work at all.

Using an external mechanism (such as a CGI perl scripts in your case) for
redirection in Tomcat is tricky at best, and doomed to failure at worst.
The reason is that the script is not really part of the servlet
request/response pipeline.  Rather, it is invoked as an exec by a Tomcat
servlet (in your case, the CGI servlet that ships with Tomcat, I assume).  

That servlet can easily do a response redirect or request forward, but the
script cannot.

Accordingly, if you stick with the script at all, modify it to return the
redirection URL, and have the servlet (a custom extension to the CGI Servlet
that ships with Tomcat probably) read and act upon this URL by doing the
redirection.

Yoav



This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential, proprietary
and/or privileged.  This e-mail is intended only for the individual(s) to
whom it is addressed, and may not be saved, copied, printed, disclosed or
used by anyone else.  If you are not the(an) intended recipient, please
immediately delete this e-mail from your computer system and notify the
sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


!DSPAM:4199125452166270918065!

Re: Buffering and redirection to the errorPage

[Steven J. Owens]

On Thu, Nov 11, 2004 at 11:28:21AM +1100, Derek Clarkson wrote:
 This sounds like something I have encountered. The basic question is
 that how do you redirect to an error page if youa re writing to the
 output stream rather than going to another JSP, and have an
 exception ?

 I thought I posted a reply to this earlier, but I don't see it in
my inbox, so maybe I should repost.

 In a nutshell, this topic makes a lot more sense if you
understand what an HTTP request and an HTTP response really look like.
My number one recommendation to folks doing web applications is to get
a packet sniffer, or a logging proxy, and take a look at what the
browser and server are actually sending back and forth.

 Each HTTP request and response look a lot like an ordinary email:
a series of header lines, a blank line, and a message body.  The
header lines are all name: value.  In an HTTP response the body is the
HTML of the page, or the binary data of an image.  In some cases there
is no body at all (a client-side redirect, for example).

 Any logical operation is handled with a header - setting a
cookie, redirecting the browser, etc.  Once the blank line separating
the header from the body has been sent, you can't go back and send
another header line.  So you _must_ do any sort of redirect before the
server starts to flush output back to the client.  If you try to set a
header after the server has already sent the blank lnie separating the
headers from the body, you'll get a java.lang.IllegalStateException.

 One way to make this easier to do is to set your buffer larger,
so the server will wait longer before flushing output to the browser.

 Another way is to use an MVC architecture.  Have the submit from
the browser go to a servlet that does any logical processing you need,
but doesn't send any output back to the user.  Instead, the controller
servlet sets request attributes and user session attributes containing
the results of the logic, then redirects the request off to the right
view page.  The view page looks for the request attributes and user
session attributes and generates HTML tags for the display.  The
controller doesn't muck with display stuff, the view page doesn't muck
with the headers.

 
-- 
Steven J. Owens
[EMAIL PROTECTED]

I'm going to make broad, sweeping generalizations and strong,
 declarative statements, because otherwise I'll be here all night and
 this document will be four times longer and much less fun to read.
 Take it all with a grain of salt. - http://darksleep.com/notablog


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Buffering and redirection to the errorPage

[Carl Olivier]

Greetings.

Maybe I should rephrase my question.  I do know how and why the behaviour is
as it is...

Rephrased question:

In earlier versions of tomcat - if an exception was thrown and bubbled up
before the response was committed, it was redirected to the error page.  No
problem.  If the reponse had already flushed, then the tomcat internals
would manually request the set error page, passing it the exception, and
would append the output of the manual error page call to the reponse, then
flush, then return.

Is that correct?

Is there a reason this is no longer being done?  I will emulate it in my
system (or at least investigate the viablility therof) if this was taken out
for a particular reason.

Thanks,

Carl

-Original Message-
From: Steven J. Owens [mailto:[EMAIL PROTECTED] 
Sent: Thursday, November 11, 2004 12:07 PM
To: Tomcat Users List
Subject: Re: Buffering and redirection to the errorPage


On Thu, Nov 11, 2004 at 11:28:21AM +1100, Derek Clarkson wrote:
 This sounds like something I have encountered. The basic question is 
 that how do you redirect to an error page if youa re writing to the 
 output stream rather than going to another JSP, and have an exception 
 ?

 I thought I posted a reply to this earlier, but I don't see it in my
inbox, so maybe I should repost.

 In a nutshell, this topic makes a lot more sense if you understand what
an HTTP request and an HTTP response really look like.
My number one recommendation to folks doing web applications is to get a
packet sniffer, or a logging proxy, and take a look at what the browser and
server are actually sending back and forth.

 Each HTTP request and response look a lot like an ordinary email:
a series of header lines, a blank line, and a message body.  The header
lines are all name: value.  In an HTTP response the body is the HTML of the
page, or the binary data of an image.  In some cases there is no body at all
(a client-side redirect, for example).

 Any logical operation is handled with a header - setting a cookie,
redirecting the browser, etc.  Once the blank line separating the header
from the body has been sent, you can't go back and send another header line.
So you _must_ do any sort of redirect before the server starts to flush
output back to the client.  If you try to set a header after the server has
already sent the blank lnie separating the headers from the body, you'll get
a java.lang.IllegalStateException.

 One way to make this easier to do is to set your buffer larger, so the
server will wait longer before flushing output to the browser.

 Another way is to use an MVC architecture.  Have the submit from the
browser go to a servlet that does any logical processing you need, but
doesn't send any output back to the user.  Instead, the controller servlet
sets request attributes and user session attributes containing the results
of the logic, then redirects the request off to the right view page.  The
view page looks for the request attributes and user session attributes and
generates HTML tags for the display.  The controller doesn't muck with
display stuff, the view page doesn't muck with the headers.

 
--
Steven J. Owens
[EMAIL PROTECTED]

I'm going to make broad, sweeping generalizations and strong,  declarative
statements, because otherwise I'll be here all night and  this document will
be four times longer and much less fun to read.
 Take it all with a grain of salt. - http://darksleep.com/notablog


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Buffering and redirection to the errorPage

[Carl Olivier]

Greetings.

I have a question with regards buffering of output and subsequent errorPage
redirection.  Maybe I am missing something.

The default buffer size for a JSP page response is 8kb.  If an exception is
thrown AFTER 8kb has been written (and the initial chunks has been
committed) then the redirection to the errorPage (if specified) does not
occur.  Does this sound right?

I have solved this during debugging by increasing the buffer size to a
larger kb amount on offending pages, then removing the setting once
debugging has occurred.

Is there anyway to enforce the redirection to the errorPage?

Thanks.

Carl

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Buffering and redirection to the errorPage

[Mike Curwen]

 If an exception is thrown AFTER 8kb has been written (and the 
 initial chunks has been committed) then the redirection to the 
 errorPage (if specified) does not occur.  Does this sound right?
 

That sounds 100% correct.

 Is there anyway to enforce the redirection to the errorPage?

Not once the buffer is flushed.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Buffering and redirection to the errorPage

[Derek Clarkson]

This sounds like something I have encountered. The basic question is that
how do you redirect to an error page if youa re writing to the output stream
rather than going to another JSP, and have an exception ?


Regards,
Derek Clarkson
Global Applications
Lonely Planet Publications
ph: (03) 8379-8000 x8041
It's not a bug - it's an undocumented feature!

-Original Message-
From: Carl Olivier [mailto:[EMAIL PROTECTED] 
Sent: Thursday, 11 November 2004 1:09 AM
To: Tomcat Users List
Subject: Buffering and redirection to the errorPage

Greetings.

I have a question with regards buffering of output and subsequent errorPage
redirection.  Maybe I am missing something.

The default buffer size for a JSP page response is 8kb.  If an exception is
thrown AFTER 8kb has been written (and the initial chunks has been
committed) then the redirection to the errorPage (if specified) does not
occur.  Does this sound right?

I have solved this during debugging by increasing the buffer size to a
larger kb amount on offending pages, then removing the setting once
debugging has occurred.

Is there anyway to enforce the redirection to the errorPage?

Thanks.

Carl

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


__
This email, including attachments, is intended only for the addressee
and may be confidential, privileged and subject to copyright.  If you
have received this email in error, please advise the sender and delete
it.  If you are not the intended recipient of this email, you must not
use, copy or disclose its content to anyone.  You must not copy or 
communicate to others content that is confidential or subject to 
copyright, unless you have the consent of the content owner.

redirection Problem

[vaneet]

Dear All,

i have a domain name and i am using no-ip software to bind my IP address (my ISP 
provides dynamic IP )

so, i have redirected my domain name: http://www.export4u.co.uk to 
micsexport.servepics.com

In tomcat Server.xml file, i have put host name
Host name=www.export4u.co.uk

now problem is:
when u visit http://www.export4u.co.uk
u click on contact us section.
If a user refreshes a page, it takes back the user to the home page which is index 
page.
I think it has to do with redirection as i am redirected

What changes do i need to do in server.xml so that i doesnt happen?

Thankx in advance.
Vaneet


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

redirection problem

[vaneet]

Dear All,

i have a domain name and i am using no-ip software to bind my IP address (my ISP 
provides dynamic IP )

so, i have redirected my domain name: http://www.export4u.co.uk to 
micsexport.servepics.com

In tomcat Server.xml file, i have put host name
Host name=www.export4u.co.uk

now problem is:
when u visit http://www.export4u.co.uk
u click on contact us section.
If a user refreshes a page, it takes back the user to the home page which is index 
page.
I think it has to do with redirection as i am redirected

What changes do i need to do in server.xml so that i doesnt happen?

Thankx in advance.
Vaneet


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Redirection problem

[vaneet]

Dear All,

 i have a domain name and i am using no-ip software to bind my IP address (my ISP 
provides dynamic IP ) 

so, i have redirected my domain name: http://www.export4u.co.uk to 
micsexport.servepics.com

In tomcat Server.xml file, i have put host name
Host name=www.export4u.co.uk

now problem is:
 when u visit http://www.export4u.co.uk
u click on contact us section.
If a user refreshes a page,  it takes back the user to the home page which is index 
page.
 I think it has to do with redirection as i am redirected
 
What changes do i need to do in server.xml so that i doesnt happen?

 Thankx in advance.
  Vaneet


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Redirection and Context Question

[Worley Brent - bworle]

I'm trying to do a redirection using Javascript on Tomcat 5.0.24
(standalone, no apache server).

The code redirects index.html to login.htm.  Here is what I have:

script language=JavaScript
location.replace('login.htm');
/script

When I do this, it appears to go into a near-endless loop of contacting the
server and attempting the redirect.  Is there a problem with Tomcat doing
this?

Also, I'm attempting to deploy an app named SIT.war into the root context.
My original context.xml contained this at the top:

Context path=/SIT docBase=SIT
 debug=0 reloadable=true crossContext=true

To get it to take over the root context, I tried this:

Context path= docBase=SIT.war
 debug=0 reloadable=true crossContext=true

However, when I did this, I lost all of my environment and resource params
listings (it could not locate the resources I defined).  Is there something
I'm missing that I need to define?

Thanks,
Brent Worley


**
The information contained in this communication is
confidential, is intended only for the use of the recipient
named above, and may be legally privileged.
If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, 
distribution, or copying of this communication is strictly
prohibited.
If you have received this communication in error,
please re-send this communication to the sender and
delete the original message or any copy of it from your
computer system. Thank You.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

SECOND TRY: Redirection and Context Question

[Worley Brent - bworle]

I'm trying to do a redirection using Javascript on Tomcat 5.0.24
(standalone, no apache server).

The code redirects index.html to login.htm.  Here is what I have:

script language=JavaScript
location.replace('login.htm');
/script

When I do this, it appears to go into a near-endless loop of contacting the
server and attempting the redirect.  Is there a problem with Tomcat doing
this?

Also, I'm attempting to deploy an app named SIT.war into the root context.
My original context.xml contained this at the top:

Context path=/SIT docBase=SIT
 debug=0 reloadable=true crossContext=true

To get it to take over the root context, I tried this:

Context path= docBase=SIT.war
 debug=0 reloadable=true crossContext=true

However, when I did this, I lost all of my environment and resource params
listings (it could not locate the resources I defined).  Is there something
I'm missing that I need to define?

Thanks,
Brent Worley


**
The information contained in this communication is
confidential, is intended only for the use of the recipient
named above, and may be legally privileged.
If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, 
distribution, or copying of this communication is strictly
prohibited.
If you have received this communication in error,
please re-send this communication to the sender and
delete the original message or any copy of it from your
computer system. Thank You.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Redirection error Tomcat 3.2.3 IIS5

[rtfrench1]

All,

New subscriber to this list and relative newbie to Tomcat. Have installed IIS5 
w/Tomcat 3.2.3 on W2K. Am having problems with redirection using isapsi. I get the 
Error 501/505 when attempting http://myserver/examples/jsp/index. I have checked 
this archive list with the same error messages to no avail.

I *can* access http://myserver:8080/examples/jsp/index.html ok and all the examples 
work fine.

Completed:
-- created jakarta virtual directory with correct permissions per documentation
-- port on workers.properties = port on server.xml (8007)
--Tomcat started with no errors
-- IIS started w/no errors
-- triple checked the path where isapi_redirect.dll is correct in IIS Manager.
-- Checked the Tomcat IISHowTo document from jakarta.apache.org. 

This is from my iis_redirect.log.

jk_uri_worker_map.c (185)]: In jk_uri_worker_map_t::uri_worker_map_free, NULL 
parameters
[jk_uri_worker_map.c (431)]: In jk_uri_worker_map_t::map_uri_to_worker, wrong 
parameters
[jk_uri_worker_map.c (431)]: In jk_uri_worker_map_t::map_uri_to_worker, wrong 
parameters

Checked the uriworkers.properties file:

#
# Simple worker configuration file
#

# Mount the servlet context to the ajp12 worker
/servlet/*=ajp12

# Mount the examples context to the ajp12 worker
/examples/*=ajp12

# Advanced mount of the examples context
# /examples/*.jsp=ajp12
# /examples/servlet/*=ajp12



Here is my workers.properties file:

#
# $Header: /home/cvs/jakarta-tomcat/src/etc/Attic/workers.properties,v 1.3.2.2 
2000/10/16 01:59:22 larryi Exp $
# $Revision: 1.3.2.2 $
# $Date: 2000/10/16 01:59:22 $
#
#
# workers.properties -
#
# This file provides jk derived plugins with with the needed information to
# connect to the different tomcat workers.
#
# As a general note, the characters $( and ) are used internally to define
# macros. Do not use them in your own configuration!!!
#
# Whenever you see a set of lines such as:
# x=value
# y=$(x)\something
#
# the final value for y will be value\something
#
# Normaly all you will need to modify is the first properties, i.e.
# workers.tomcat_home, workers.java_home and ps. Most of the configuration
# is derived from these.
#
# When you are done updating workers.tomcat_home, workers.java_home and ps
# you should have 3 workers configured:
#
# - An ajp12 worker that connects to localhost:8007
# - An ajp13 worker that connects to localhost:8009
# - A jni inprocess worker.
# - A load balancer worker
#
# However by default the plugins will only use the ajp12 worker. To have
# the plugins use other workers you should modify the worker.list property.
#
#

#
# workers.tomcat_home should point to the location where you
# installed tomcat. This is where you have your conf, webapps and lib
# directories.
#
workers.tomcat_home=d:\tomcat

#
# workers.java_home should point to your Java installation. Normally
# you should have a bin and lib directories beneath it.
#
workers.java_home=d:\jdk

#
# You should configure your environment slash... ps=\ on NT and / on UNIX
# and maybe something different elsewhere.
#
ps=\
# ps=/

#
#-- ADVANCED MODE 
#-
#

#
#-- DEFAULT worket list --
#-
#
#
# The workers that your plugins should create and work with
#
worker.list=ajp12, ajp13

#
#-- DEFAULT ajp12 WORKER DEFINITION --
#-
#

#
# Defining a worker named ajp12 and of type ajp12
# Note that the name and the type do not have to match.
#
worker.ajp12.port=8007
worker.ajp12.host=localhost
worker.ajp12.type=ajp12
#
# Specifies the load balance factor when used with
# a load balancing worker.
# Note:
#   lbfactor must be  0
#   Low lbfactor means less work done by the worker.
worker.ajp12.lbfactor=1

#
#-- DEFAULT ajp13 WORKER DEFINITION --
#-
#

#
# Defining a worker named ajp13 and of type ajp13
# Note that the name and the type do not have to match.
#
worker.ajp13.port=8009
worker.ajp13.host=localhost
worker.ajp13.type=ajp13
#
# Specifies the load balance factor when used with
# a load balancing worker.
# Note:
#   lbfactor must be  0
#   Low lbfactor means less work done by the worker.
worker.ajp13.lbfactor=1

#
# Specify the size of the open connection cache.
#worker.ajp13.cachesize

#
#-- DEFAULT LOAD BALANCER WORKER DEFINITION --
#-
#

#
# The loadbalancer (type lb) workers perform wighted round-robin
# load balancing with sticky sessions.
# Note:
#   If a worker dies, the load balancer will check its state
#once in a while. Until then all work is redirected to peer
#workers

Tomcat Redirection Error

[rtfrench1]

Tomcat 3.2.3 with IIS 5.0 with Win2k.

When using http://myserver/examples/jsp/index I get a 404 error. My tomcat.log is:

2004-04-12 14:23:04 - ContextManager: Adding context Ctx( /examples )
2004-04-12 14:23:04 - ContextManager: Adding context Ctx( /admin )
2004-04-12 14:23:04 - ContextManager: Adding context Ctx(  )
2004-04-12 14:23:04 - ContextManager: Adding context Ctx( /test )
2004-04-12 14:23:10 - PoolTcpConnector: Starting HttpConnectionHandler on 8080
2004-04-12 14:23:10 - PoolTcpConnector: Starting Ajp12ConnectionHandler on 8007
2004-04-12 14:23:11 - Ctx(  ): 404 R(  + /jakarta/isapi_redirect.dll + null) null
2004-04-12 14:30:24 - Ctx(  ): 404 R(  + /jakarta/isapi_redirect.dll + null) null

IIS is running and has isapi_redirect.dll installed/defined. Jakarta is defined in 
registry with green up arrow in IIS.

Ok so tomcat cannot redirect for a reason. I've defined jakart according to all the 
documentation including TomcatIISHow To. Any ideas??

http://myserver:8080/examples/jsp/index.html does work.

server.xml and worker.properties file has same port # for ajp12: 8007.


Thank you ,

Roger

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Redirection of JSP's to iPlanet Web Server

[Anantharam S]

Hi all

I managed to configure iPlanet to redirect the requests from JBOSS 321. I would like 
to thank Rick for his timely and invaluable help :)


First, you need to add the below lines into your magnus.conf right on top of the 
already existing init parameters: 

Init fn=load-modules funcs=jk_init,jk_service shlib=/PATH TO 
/nsapi_redirector.dll 

Init fn=jk_init worker_file=/PATH TO/workers.properties log_level=debug 
log_file=PATH TO/nsapi.log

Inside your workers.properties file, set worker.jboss.host to your FQDN.

Now, in your obj.conf file, enter these lines in the Object name=default section:
NameTrans fn=assign-name from=/examples/* name=jboss
NameTrans fn=assign-name from=/jmx-console/* name=jboss
NameTrans fn=assign-name from=/jmx-console* name=jboss
NameTrans fn=assign-name from=/idm/* name=jboss
NameTrans fn=assign-name from=/idm* name=jboss

Now, underneath the Object name=default section, make a new section:
Object name=jboss
ObjectType fn=force-type type=text/plain
Service fn=jk_service worker=jboss
/Object

Stop and start your webserver - you should see a message like:
iPlanet-WebServer-Enterprise/6.0SP5 B10/31/2002 16:22
In jk_init.
   Worker file = /opt/iplanet/webserver/https-servername/config/workers.properties.
   Log level = debug.
   Log File = /opt/iplanet/webserver/https-servername/logs/nsapi.log

If not, you probably will have to experiment a bit on the order in which you have the 
directives entered in magnus.conf and obj.conf.

If everything is working properly you should be able to access this page:
http://youservername:port/jmx-console
and have the JBoss admin console appear.  


Thanks Rick  :) .. couldn't have done it without you 

With regards
Ananth

Redirection of JSP to iPlanet Web Server

[Anantharam S]

Hi,

I have been trying for a while now to configure iPlanet web server (6.x) to send 
servlet and JSP requests to Tomcat (4.1.x) using the Tomcat redirector plugin. 

Asper the documentation of APACHE ( 
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/jk/neshowto.html ) a dll file ( 
nsapi_redirect.dll ) is required to configure the redirection of the jsp's from the 
iplanet web server to TOMCAT, but I am unable to find out the location of this dll 
file in the connectors binaries :( 

I would be grateful if anyone could guide me on the process of redirecting the jsp 
requests from TOMCAT to the iPlanet web server

Thanks in advance;
Ananth

Redirection of JSP's to iPlanet Web Server

[Anantharam S]

Hi,

I have been trying for a while now to configure iPlanet web server (6.x) to send 
servlet and JSP requests to Tomcat (4.1.x) using the Tomcat redirector plugin. 

Asper the documentation of APACHE ( 
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/jk/neshowto.html ) a dll file ( 
nsapi_redirect.dll ) is required to configure the redirection of the jsp's from the 
iplanet web server to TOMCAT, but I am unable to find out the location of this dll 
file in the connectors binaries :( 

I would be grateful if anyone could guide me on the process of redirecting the jsp 
requests from TOMCAT to the iPlanet web server

Thanks in advance;
Ananth

Re: Redirection of JSP to iPlanet Web Server

[Bill Barker]

I'm pretty sure that there isn't a Jakarta binary for Windows (and if there
is, it would be *very* old :).  You could try checking the Tomcat 3.x
download sites to see if there is an old version floating around.  This is
one of the least maintained mod_jk versions, for the simple reason that
Netscape/iPlanet/SunONE users don't seem interested in volunteering to help
maintain it.  It gets global fixes, but not much else.

If you have access to a machine with MSVC, probably your best bet is to
build it yourself from source.


Anantharam S [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hi,

I have been trying for a while now to configure iPlanet web server (6.x) to
send servlet and JSP requests to Tomcat (4.1.x) using the Tomcat redirector
plugin.

Asper the documentation of APACHE (
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/jk/neshowto.html ) a dll
file ( nsapi_redirect.dll ) is required to configure the redirection of the
jsp's from the iplanet web server to TOMCAT, but I am unable to find out the
location of this dll file in the connectors binaries :(

I would be grateful if anyone could guide me on the process of redirecting
the jsp requests from TOMCAT to the iPlanet web server

Thanks in advance;
Ananth





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Apache redirection to Tomcat, but with JDBC security realms

[Tang Wern Chait]

Has anyone tried Apache redirection to Tomcat, on Java code that makes uses of 
JDBD security realms?

Assuming the redirection from Apache to Tomcat works fine when I type 
'http://localhost/examples/servlets/index.html'

But for my own code, I include url 'alerts.do' inside security realm.  Typing the 
url will bring user to page 'login.jsp'.  This works fine if I type 
'http:8080//localhost/rms/alerts.do'.  

But if I try redirection by typing 'http://localhost/rms/alerts.do', I get error 
page The page cannot be displayed

Obviously, Apache redirection tries to find page 'alerts.do' instead of 
'login.jsp'.

How, can I rectify this problem?

session redirection automatic

[Philippe Valle]

hi,

I use tomcat 4.1.29 and my server.xml have Session expire  to 60.
When Session expired i want redirect automaticly the user on 
sessionerror.jsp .
how i do that ? this test is do on jsp pages or servlet ?
Did you have an example ?

thanks.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: error-page redirection

[Shapira, Yoav]

Howdy,
So your servlet throws a LuckyException??  Http Servlets should throw a
ServletException or IOException.  Alternatively, you could add an
error-page tag to your web.xml with LuckyException as the exception
type and a custom error page as the URL.

Yoav Shapira
Millennium ChemInformatics


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, November 07, 2003 9:58 AM
To: [EMAIL PROTECTED]
Subject: error-page redirection

Hello everyone,
 I am trying to display an error page if user enters a wrong number.
The
number has to be between 1 an d 10. I get following error:
type Exception report


message


description The server encountered an internal error () that prevented
it
from fulfilling this request.


exception
LuckyException
 at LuckyNumber1Servlet.validate_number(Unknown Source)
 at LuckyNumber1Servlet.doGet(Unknown Source)
 at
javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
 at
javax.servlet.http.HttpServlet.service(HttpServlet.java:856)

Folks, I tried various ways to fix this issue. spent many hours
searching
thru books and internet, but could not find a way out.
Can someone please point out the bug here?
Thanks
Raju Lokhande
***

**
Here is my servlet code:
import java.io.*;
import java.util.*;
import java.sql.*;
import javax.servlet.*;
import javax.servlet.http.*;

/**
 * This is a simple example of an HTTP Servlet.  It responds to the GET
 * method of the HTTP protocol.
 */
public class LuckyNumber1Servlet extends HttpServlet
  {

private int inp_int;
  public void init() throws ServletException {
  ServletContext servletContext = getServletContext();
  servletContext.setAttribute(ServletTotal, new
Integer(0));

  } // end of init


  public void validate_number(String in_str) throws LuckyException
{

inp_int = Integer.parseInt( in_str );

if ( inp_int  1 || inp_int  10 )
throw new LuckyException();

  }
public void doGet (HttpServletRequest request,
   HttpServletResponse response)
throws ServletException, IOException {

  response.setContentType(text/html);
  response.setBufferSize(8192);
  PrintWriter out = response.getWriter();

  // then write the data of the response
  out.println(html +
  headtitleHello/title/head);

   // then write the data of the response
  out.println(body  bgcolor=\#ff\ +
 img src=\duke.waving.gif\ +
 h2My lucky number is 7. What's yours?/h2 +
 form method=\get\ +
 input type=\text\ name=\lnumber\ size=\25\ +
 p/p +
 input type=\submit\ value=\Submit\ +
 input type=\reset\ value=\Reset\ +
 /form);

String lnumber = request.getParameter(lnumber);

Integer SessionTotal;
int temp_int;

if ( lnumber != null  lnumber.length()  0 ) {

  try {
   validate_number( lnumber );
  }
  catch ( LuckyException not_ignored) {
response.resetBuffer();
throw  new ServletException( not_ignored ) ;
  }

  HttpSession session = request.getSession( true );

  synchronized(session) {
SessionTotal =
(Integer) session.getAttribute
( SessionTotal);

if ( SessionTotal == null )
  SessionTotal = new Integer(0);

temp_int =  SessionTotal.intValue() ;
int temp_count = temp_int + Integer.parseInt(
lnumber);

Integer temp_integer = new Integer(
temp_count);

session.setAttribute ( SessionTotal,
temp_integer
);
}

ServletContext servletContext =
getServletContext
();

Integer ServletTotal =
  (Integer) servletContext.getAttribute
(ServletTotal);

if ( ServletTotal == null )
  ServletTotal = new Integer( 0 );

int temp_int2 =  ServletTotal.intValue() ;
int temp_count2 = temp_int2 + Integer.parseInt(
lnumber);
Integer temp_integer2 = new Integer(
temp_count2 );
servletContext.setAttribute(ServletTotal,
temp_integer2);

RequestDispatcher dispatcher =
   getServletContext().getRequestDispatcher
(/lucky2);

if (dispatcher != null)
  dispatcher.include(request, response

RE: error-page redirection

[Anton Modaresi]

I think you should compile your application with debug information,
that way you can see what line in your application causes it.



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: den 7 november 2003 15:58
To: [EMAIL PROTECTED]
Subject: error-page redirection


Hello everyone,
 I am trying to display an error page if user enters a wrong number. The
number has to be between 1 an d 10. I get following error:
type Exception report


message


description The server encountered an internal error () that prevented it
from fulfilling this request.


exception
LuckyException
 at LuckyNumber1Servlet.validate_number(Unknown Source)
 at LuckyNumber1Servlet.doGet(Unknown Source)
 at
javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
 at
javax.servlet.http.HttpServlet.service(HttpServlet.java:856)

Folks, I tried various ways to fix this issue. spent many hours searching
thru books and internet, but could not find a way out.
Can someone please point out the bug here?
Thanks
Raju Lokhande

*
Here is my servlet code:
import java.io.*;
import java.util.*;
import java.sql.*;
import javax.servlet.*;
import javax.servlet.http.*;

/**
 * This is a simple example of an HTTP Servlet.  It responds to the GET
 * method of the HTTP protocol.
 */
public class LuckyNumber1Servlet extends HttpServlet
  {

private int inp_int;
  public void init() throws ServletException {
  ServletContext servletContext = getServletContext();
  servletContext.setAttribute(ServletTotal, new
Integer(0));

  } // end of init


  public void validate_number(String in_str) throws LuckyException {

inp_int = Integer.parseInt( in_str );

if ( inp_int  1 || inp_int  10 )
throw new LuckyException();

  }
public void doGet (HttpServletRequest request,
   HttpServletResponse response)
throws ServletException, IOException {

  response.setContentType(text/html);
  response.setBufferSize(8192);
  PrintWriter out = response.getWriter();

  // then write the data of the response
  out.println(html +
  headtitleHello/title/head);

   // then write the data of the response
  out.println(body  bgcolor=\#ff\ +
 img src=\duke.waving.gif\ +
 h2My lucky number is 7. What's yours?/h2 +
 form method=\get\ +
 input type=\text\ name=\lnumber\ size=\25\ +
 p/p +
 input type=\submit\ value=\Submit\ +
 input type=\reset\ value=\Reset\ +
 /form);

String lnumber = request.getParameter(lnumber);

Integer SessionTotal;
int temp_int;

if ( lnumber != null  lnumber.length()  0 ) {

  try {
   validate_number( lnumber );
  }
  catch ( LuckyException not_ignored) {
response.resetBuffer();
throw  new ServletException( not_ignored ) ;
  }

  HttpSession session = request.getSession( true );

  synchronized(session) {
SessionTotal =
(Integer) session.getAttribute
( SessionTotal);

if ( SessionTotal == null )
  SessionTotal = new Integer(0);

temp_int =  SessionTotal.intValue() ;
int temp_count = temp_int + Integer.parseInt(
lnumber);

Integer temp_integer = new Integer( temp_count);

session.setAttribute ( SessionTotal, temp_integer
);
}

ServletContext servletContext = getServletContext
();

Integer ServletTotal =
  (Integer) servletContext.getAttribute
(ServletTotal);

if ( ServletTotal == null )
  ServletTotal = new Integer( 0 );

int temp_int2 =  ServletTotal.intValue() ;
int temp_count2 = temp_int2 + Integer.parseInt(
lnumber);
Integer temp_integer2 = new Integer( temp_count2 );
servletContext.setAttribute(ServletTotal,
temp_integer2);

RequestDispatcher dispatcher =
   getServletContext().getRequestDispatcher
(/lucky2);

if (dispatcher != null)
  dispatcher.include(request, response);

  }
  out.println(/body/html);
  out.close();
} // end of doGet().

public String getServletInfo() {
return The LuckyNumber1Servlet servlet types a number

error-page redirection

[Raju . X . Lokhande]

Hello everyone,
 I am trying to display an error page if user enters a wrong number. The
number has to be between 1 an d 10. I get following error:
type Exception report


message


description The server encountered an internal error () that prevented it
from fulfilling this request.


exception
LuckyException
 at LuckyNumber1Servlet.validate_number(Unknown Source)
 at LuckyNumber1Servlet.doGet(Unknown Source)
 at
javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
 at
javax.servlet.http.HttpServlet.service(HttpServlet.java:856)

Folks, I tried various ways to fix this issue. spent many hours searching
thru books and internet, but could not find a way out.
Can someone please point out the bug here?
Thanks
Raju Lokhande
*
Here is my servlet code:
import java.io.*;
import java.util.*;
import java.sql.*;
import javax.servlet.*;
import javax.servlet.http.*;

/**
 * This is a simple example of an HTTP Servlet.  It responds to the GET
 * method of the HTTP protocol.
 */
public class LuckyNumber1Servlet extends HttpServlet
  {

private int inp_int;
  public void init() throws ServletException {
  ServletContext servletContext = getServletContext();
  servletContext.setAttribute(ServletTotal, new
Integer(0));

  } // end of init


  public void validate_number(String in_str) throws LuckyException {

inp_int = Integer.parseInt( in_str );

if ( inp_int  1 || inp_int  10 )
throw new LuckyException();

  }
public void doGet (HttpServletRequest request,
   HttpServletResponse response)
throws ServletException, IOException {

  response.setContentType(text/html);
  response.setBufferSize(8192);
  PrintWriter out = response.getWriter();

  // then write the data of the response
  out.println(html +
  headtitleHello/title/head);

   // then write the data of the response
  out.println(body  bgcolor=\#ff\ +
 img src=\duke.waving.gif\ +
 h2My lucky number is 7. What's yours?/h2 +
 form method=\get\ +
 input type=\text\ name=\lnumber\ size=\25\ +
 p/p +
 input type=\submit\ value=\Submit\ +
 input type=\reset\ value=\Reset\ +
 /form);

String lnumber = request.getParameter(lnumber);

Integer SessionTotal;
int temp_int;

if ( lnumber != null  lnumber.length()  0 ) {

  try {
   validate_number( lnumber );
  }
  catch ( LuckyException not_ignored) {
response.resetBuffer();
throw  new ServletException( not_ignored ) ;
  }

  HttpSession session = request.getSession( true );

  synchronized(session) {
SessionTotal =
(Integer) session.getAttribute
( SessionTotal);

if ( SessionTotal == null )
  SessionTotal = new Integer(0);

temp_int =  SessionTotal.intValue() ;
int temp_count = temp_int + Integer.parseInt(
lnumber);

Integer temp_integer = new Integer( temp_count);

session.setAttribute ( SessionTotal, temp_integer
);
}

ServletContext servletContext = getServletContext
();

Integer ServletTotal =
  (Integer) servletContext.getAttribute
(ServletTotal);

if ( ServletTotal == null )
  ServletTotal = new Integer( 0 );

int temp_int2 =  ServletTotal.intValue() ;
int temp_count2 = temp_int2 + Integer.parseInt(
lnumber);
Integer temp_integer2 = new Integer( temp_count2 );
servletContext.setAttribute(ServletTotal,
temp_integer2);

RequestDispatcher dispatcher =
   getServletContext().getRequestDispatcher
(/lucky2);

if (dispatcher != null)
  dispatcher.include(request, response);

  }
  out.println(/body/html);
  out.close();
} // end of doGet().

public String getServletInfo() {
return The LuckyNumber1Servlet servlet types a number.;

}
 } // end of class LuckyNumber1Servlet

*LuckyException.java ***
import javax.servlet.*;
public class LuckyException extends ServletException {

public LuckyException () { }

   /*
public LuckyException (String msg) {

Re: Redirection loop

[Jon Haugsand]

* Bill Barker
 This should make you happy, since, indeed, TC 4.1.x will figure this out and
 allow access to the form-login-page even if it is otherwise protected.  The
 TC 3.x line doesn't have this feature (although it would be easy enough to
 add to TC 3.3.2 if anyone actually wanted it :).

You were right, of course.  Everything is running nicely.  I haven't
figured out some other issues yet, but I guess that will get in place
after my learning period.  

Anyway, how should the fragment look like in order to correctly state
that all, but the login page should go to the login page?

-- 
 Jon Haugsand, [EMAIL PROTECTED]
 http://www.norges-bank.no


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Redirection loop

[Jon Haugsand]

I try to deploy an application developed by someone else, but her is
what happens when I try to access it:

telnet localhost 8082
GET /unni/jsp/tilganger/tlgLogin.jsp
HTTP/1.0 302 Found
Content-Type: text/html
Location: http://localhost:8082/unni/jsp/tilganger/tlgLogin.jsp
Content-Length: 186
Date: Wed, 25 Jun 2003 11:21:03 GMT
Servlet-Engine: Tomcat Web Server/3.2.4 (JSP 1.1; Servlet 2.2; Java 1.3.1_06; Linux 
2.4.18-4GB i386; java.vendor=Sun Microsystems Inc.)

headtitleDocument moved/title/head
bodyh1Document moved/h1
This document has moved a 
href=http://localhost:8082/unni/jsp/tilganger/tlgLogin.jsp;here/a.p
/body
Connection closed by foreign host.

Where can I (or my collegue) have set this up such that it constantly
redirects to itself?

-- 
 Jon Haugsand, [EMAIL PROTECTED]
 http://www.norges-bank.no


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Redirection loop

[Tim Funk]

There is probably a security constraint on tlgLogin.jsp and the login page is 
tlgLogin.jsp which invokes the security constraint and the login page is 
tlgLogin.jsp which invokes the security constraint and the login page is 
tlgLogin.jsp which invokes the security constraint ...

Or tlgLogin.jsp is badly coded to perform a redirect to itself based on a 
wacky condition.

-Tim

Jon Haugsand wrote:
I try to deploy an application developed by someone else, but her is
what happens when I try to access it:
telnet localhost 8082
GET /unni/jsp/tilganger/tlgLogin.jsp
HTTP/1.0 302 Found
Content-Type: text/html
Location: http://localhost:8082/unni/jsp/tilganger/tlgLogin.jsp
Content-Length: 186
Date: Wed, 25 Jun 2003 11:21:03 GMT
Servlet-Engine: Tomcat Web Server/3.2.4 (JSP 1.1; Servlet 2.2; Java 1.3.1_06; Linux 
2.4.18-4GB i386; java.vendor=Sun Microsystems Inc.)
headtitleDocument moved/title/head
bodyh1Document moved/h1
This document has moved a 
href=http://localhost:8082/unni/jsp/tilganger/tlgLogin.jsp;here/a.p
/body
Connection closed by foreign host.
Where can I (or my collegue) have set this up such that it constantly
redirects to itself?


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Redirection loop

[Jon Haugsand]

* Tim Funk
 There is probably a security constraint on tlgLogin.jsp and the login
 page is tlgLogin.jsp which invokes the security constraint and the
 login page is tlgLogin.jsp which invokes the security constraint and
 the login page is tlgLogin.jsp which invokes the security constraint
 ...

 Or tlgLogin.jsp is badly coded to perform a redirect to itself based
 on a wacky condition.

Hmm, it looks reasonable, but shouldn't tomcat figure out that it you
somehow must get through to the guard that identifies people?  Here is
perhaps the relevant parts of web.xml.  By the way, I had Tomcat 3.2.4
running, but am now upgrading to 4.1.24

security-constraint
web-resource-collection
web-resource-name Tilgangsystem/web-resource-name
url-pattern/*/url-pattern
/web-resource-collection
auth-constraint
role-namesuperuser/role-name
/auth-constraint
/security-constraint

login-config
auth-methodFORM/auth-method
form-login-config
form-login-page/jsp/tilganger/tlgLogin.jsp/form-login-page
form-error-page/jsp/tilganger/tlgError.jsp/form-error-page
/form-login-config
/login-config

-- 
 Jon Haugsand, [EMAIL PROTECTED]
 http://www.norges-bank.no


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Redirection loop

[Tim Funk]

It doesn't. I don't think the spec accounts for it either. (But I am not in 
the mood to reread that section at this moment)

-Tim

Jon Haugsand wrote:
Hmm, it looks reasonable, but shouldn't tomcat figure out that it you
somehow must get through to the guard that identifies people?  Here is
perhaps the relevant parts of web.xml.  By the way, I had Tomcat 3.2.4
running, but am now upgrading to 4.1.24


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Redirection loop

[Bill Barker]

Jon Haugsand [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
 * Tim Funk
  There is probably a security constraint on tlgLogin.jsp and the login
  page is tlgLogin.jsp which invokes the security constraint and the
  login page is tlgLogin.jsp which invokes the security constraint and
  the login page is tlgLogin.jsp which invokes the security constraint
  ...
 
  Or tlgLogin.jsp is badly coded to perform a redirect to itself based
  on a wacky condition.

 Hmm, it looks reasonable, but shouldn't tomcat figure out that it you
 somehow must get through to the guard that identifies people?  Here is
 perhaps the relevant parts of web.xml.  By the way, I had Tomcat 3.2.4
 running, but am now upgrading to 4.1.24

This should make you happy, since, indeed, TC 4.1.x will figure this out and
allow access to the form-login-page even if it is otherwise protected.  The
TC 3.x line doesn't have this feature (although it would be easy enough to
add to TC 3.3.2 if anyone actually wanted it :).


 security-constraint
 web-resource-collection
 web-resource-name Tilgangsystem/web-resource-name
 url-pattern/*/url-pattern
 /web-resource-collection
 auth-constraint
 role-namesuperuser/role-name
 /auth-constraint
 /security-constraint

 login-config
 auth-methodFORM/auth-method
 form-login-config
 form-login-page/jsp/tilganger/tlgLogin.jsp/form-login-page
 form-error-page/jsp/tilganger/tlgError.jsp/form-error-page
 /form-login-config
 /login-config

 --
  Jon Haugsand, [EMAIL PROTECTED]
  http://www.norges-bank.no




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Apache, Tomcat/JBoss, SSL, redirection

[David Salbego]

As I have not received any hints, is there a better list I should be posting this type 
of question to?  Like I said, I think the question is reasonable but I might be 
overlooking something completely obvious.  

thanks again for your assistance,

--Dave

At 04:25 PM 6/10/2003, David Salbego wrote:
Hello All,

New to the list, did some searching in the archives and didn't see an answer offhand 
but I may have missed it (my apologies!)

Config:

Server: HP-UX_Apache-based_Web_Server/2.0.45 (Unix) mod_perl/1.99_08 Perl/v5.6.1 
PHP/4.2.3 mod_ssl/2.0.45 OpenSSL/0.9.6i DAV/2 mod_jk/1.2.0

The above is from the Apache web server running on the HP-UX machine we are doing the 
development on.  

I have integrated Apache, mod_jk, Tomcat 4.1, and JBoss 3.0.7 together and they run 
fine.  I did not compile anything; HP supplies a pre-configured suite of products 
(Apache and Tomcat, among others); I simply installed JBoss 3.0.7 (w/ Tomcat) and 
pointed JBoss to use HP's pre-installed Tomcat instead of its own.  
Test applications show the whole deal is working, but we have problems when we 
attempt to use SSL.

In a nutshell, it appears mod_jk is the culprit:  when going to a JkMount'd directory 
(and not supplying a filename in the URL), mod_jk appears to redirect the web client 
to the wrong location (everything is correct except the _protocol_, i.e. http is 
returned instead of https)

Example:

https://www.myserver.com/testapp/index.jsp

works fine.

https://www.myserver.com/testapp/

redirects to:

http://www.myserver.com:443/testapp/index.jsp

and the above returns the standard You are talking plain HTTP to
an SSL-enabled web server...  error.

Logs from mod_jk:

[Fri Jun 06 15:02:00 2003]  [jk_uri_worker_map.c (502)]: 
jk_uri_worker_map_t::map_uri_to_worker, Found a context match ajp13 - /testapp/
[Fri Jun 06 15:02:01 2003]  [jk_uri_worker_map.c (477)]: Attempting to map URI 
'/testapp/'
[Fri Jun 06 15:02:01 2003]  [jk_uri_worker_map.c (502)]: 
jk_uri_worker_map_t::map_uri_to_worker, Found a context match ajp13 - /testapp/
[Fri Jun 06 15:02:01 2003]  [jk_ajp_common.c (532)]: ajp_unmarshal_response: 
Header[0] [Location] = [http://www.myserver.com:443/testapp/index.jsp]


I can supply any needed config files but I didn't want to include them in this 
initial email.

Is the problem I'm seeing due to the way the programs were compiled and packaged by 
HP?  The HP admin would highly prefer to use these pre-packaged solutions as opposed 
to compiling from source, although we can do that if we have to.

Has anyone else seen this problem?

Please CC: me directly as well as I have this list filtered into a mailbox I cannot 
read every day.

Thanks for your help,

--Dave



David Salbego  ([EMAIL PROTECTED])
Unix Infrastructure Group Manager
Computing and Instrumentation Solutions
Argonne National Laboratory
Phone: +1 630.252.7837  Fax: +1 630.252.9689 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


David Salbego  ([EMAIL PROTECTED])
Unix Infrastructure Group Manager
Computing and Instrumentation Solutions
Argonne National Laboratory
Phone: +1 630.252.7837  Fax: +1 630.252.9689 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Apache, Tomcat/JBoss, SSL, redirection

[Nikola Milutinovic]

 As I have not received any hints, is there a better list I should be posting this 
 type of question to?
  Like I said, I think the question is reasonable but I might be overlooking 
 something completely obvious.

Don't give up on us :-)

The error you describe is strange, I've read it just now and I'm puzzled. Could you 
try to eliminate mod_jk from the picture?

Run a normal Coyote HTTPS on port 8083 and try the same thing. The redirection is 
Tomcat's job and maybe it is getting wrong info from mod_jk.

Nix.

Apache, Tomcat/JBoss, SSL, redirection

[David Salbego]

Hello All,

New to the list, did some searching in the archives and didn't see an answer offhand 
but I may have missed it (my apologies!)

Config:

Server: HP-UX_Apache-based_Web_Server/2.0.45 (Unix) mod_perl/1.99_08 Perl/v5.6.1 
PHP/4.2.3 mod_ssl/2.0.45 OpenSSL/0.9.6i DAV/2 mod_jk/1.2.0

The above is from the Apache web server running on the HP-UX machine we are doing the 
development on.  

I have integrated Apache, mod_jk, Tomcat 4.1, and JBoss 3.0.7 together and they run 
fine.  I did not compile anything; HP supplies a pre-configured suite of products 
(Apache and Tomcat, among others); I simply installed JBoss 3.0.7 (w/ Tomcat) and 
pointed JBoss to use HP's pre-installed Tomcat instead of its own.  
Test applications show the whole deal is working, but we have problems when we attempt 
to use SSL.

In a nutshell, it appears mod_jk is the culprit:  when going to a JkMount'd directory 
(and not supplying a filename in the URL), mod_jk appears to redirect the web client 
to the wrong location (everything is correct except the _protocol_, i.e. http is 
returned instead of https)

Example:

https://www.myserver.com/testapp/index.jsp

works fine.

https://www.myserver.com/testapp/

redirects to:

http://www.myserver.com:443/testapp/index.jsp

and the above returns the standard You are talking plain HTTP to
an SSL-enabled web server...  error.

Logs from mod_jk:

[Fri Jun 06 15:02:00 2003]  [jk_uri_worker_map.c (502)]: 
jk_uri_worker_map_t::map_uri_to_worker, Found a context match ajp13 - /testapp/
[Fri Jun 06 15:02:01 2003]  [jk_uri_worker_map.c (477)]: Attempting to map URI 
'/testapp/'
[Fri Jun 06 15:02:01 2003]  [jk_uri_worker_map.c (502)]: 
jk_uri_worker_map_t::map_uri_to_worker, Found a context match ajp13 - /testapp/
[Fri Jun 06 15:02:01 2003]  [jk_ajp_common.c (532)]: ajp_unmarshal_response: 
Header[0] [Location] = [http://www.myserver.com:443/testapp/index.jsp]


I can supply any needed config files but I didn't want to include them in this initial 
email.

Is the problem I'm seeing due to the way the programs were compiled and packaged by 
HP?  The HP admin would highly prefer to use these pre-packaged solutions as opposed 
to compiling from source, although we can do that if we have to.

Has anyone else seen this problem?

Please CC: me directly as well as I have this list filtered into a mailbox I cannot 
read every day.

Thanks for your help,

--Dave



David Salbego  ([EMAIL PROTECTED])
Unix Infrastructure Group Manager
Computing and Instrumentation Solutions
Argonne National Laboratory
Phone: +1 630.252.7837  Fax: +1 630.252.9689 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Multiple Tomcat-IIS redirection.

[Nir Bregman]

Hi.
I have a problem to redirect IIS to Tomcat installation in case i have more
than one Tomcat installation
on my computer.
I'm working on win2000, and have two separated Tomcat installations on a
single machine.
I need IIS redirect filters to be installed - one filter for each Tomcat.
The problem is that when i create the second isapi_redirect filter i see
strange behavior, as if when
you have more than one filter the filters kind of effect each other.
I tried to change the priorities of the filters but it always behave the
same.
I also tried to use a differant name for the isapi_redirect.dll, it didn't
help...(i changed the .properties file name as well).
Please help me to figure it out...
Thanks.
Nir Bregman.


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

ssl redirection? in tomcat

[Jason Pyeron]

given 

http://server/context/securedir/foo.html 

needs to redirect to 

https://server/context/securedir/foo.html


and 

https://server/context/nosslhere/bar.html

to

http://server/context/nosslhere/bar.html


cant seem to find any docs on this subject.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- Jason Pyeron   http://www.pyerotechnics.com   -
- Owner  Lead  Pyerotechnics Development, Inc. -
- +1 410 808 6646 (c)   500 West University Parkway #1S -
- +1 410 467 2266 (f)   Baltimore, Maryland  21210-3253 -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

This message is for the designated recipient only and may contain 
privileged, proprietary, or otherwise private information. If you
have received it in error, purge the message from your system and 
notify the sender immediately.  Any other use of the email by you 
is prohibited.




--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: ssl redirection? in tomcat

[Jason Pyeron]

http - https solved:

security-constraint
 web-resource-collection
  web-resource-name/
  url-pattern/securedir/url-pattern
  url-pattern/securedir//url-pattern
  url-pattern/securedir/*/url-pattern
  url-pattern/securedir/**/url-pattern
 /web-resource-collection
 user-data-constraint
  transport-guaranteeCONFIDENTIAL/transport-guarantee
 /user-data-constraint
/security-constraint


any ideas on https - http?

-jason pyeron

On Tue, 24 Dec 2002, Jason Pyeron wrote:


given 

http://server/context/securedir/foo.html 

needs to redirect to 

https://server/context/securedir/foo.html


and 

https://server/context/nosslhere/bar.html

to

http://server/context/nosslhere/bar.html


cant seem to find any docs on this subject.



-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- Jason Pyeron   http://www.pyerotechnics.com   -
- Owner  Lead  Pyerotechnics Development, Inc. -
- +1 410 808 6646 (c)   500 West University Parkway #1S -
- +1 410 467 2266 (f)   Baltimore, Maryland  21210-3253 -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

This message is for the designated recipient only and may contain 
privileged, proprietary, or otherwise private information. If you
have received it in error, purge the message from your system and 
notify the sender immediately.  Any other use of the email by you 
is prohibited.




--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

iis redirection to linux tomcat machine

[Jose Antonio Martinez]

i have installed the isapi filter in the iis for
redirection of jsp pages to a linux machine (it has a
tomcat server).

i have followed the documentation at:

http://members.ozemail.com.au/~lampante/howto/tomcat/iisnt/#6


the array is green now , but when i try to view jsp
samples, there is a problem: iis says it cant find the
module !!!

any idea?



___
Yahoo! Messenger
Nueva versión: Webcam, voz, y mucho más ¡Gratis! 
Descárgalo ya desde http://messenger.yahoo.es

--
To unsubscribe, e-mail:   mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org

Re: iis redirection to linux tomcat machine

[Jose Antonio Martinez]

here is the redirector isapi log:

#  Begin worker.properties **
worker.ajp13.type=ajp13

#
# Specifies the load balance factor when used with
# a load balancing worker.
# Note:
#   lbfactor must be  0
#   Low lbfactor means less work done by the
worker.
worker.ajp13.lbfactor=1

#
# Specify the size of the open connection cache.
#worker.ajp13.cachesize

#
#-- DEFAULT LOAD BALANCER WORKER DEFINITION
--
#-
#

#
# The loadbalancer (type lb) worker perform weighted
round-robin
# load balancing with sticky sessions.
# Note:
#   If a worker dies, the load balancer will
check its state
#once in a while. Until then all work is
redirected to peer
#worker.
worker.loadbalancer.type=lb
worker.loadbalancer.balanced_workers=ajp13

#
# worker.tomcat_home should point to the location
where you
# installed tomcat. This is where you have your conf,
webapps and lib
# directories.
#
worker.tomcat_home=C:\jakarta-tomcat-4.0.1

#
# worker.java_home should point to your Java
installation. Normally
# you should have a bin and lib directories beneath
it.
#
worker.java_home=C:\jdk1.3.1

#
# You should configure your environment slash... ps=\
on NT and / on UNIX
# and maybe something different elsewhere.
#
ps=\

#
#-- ADVANCED MODE

#-
#

#
#-- DEFAULT worker list
--
#-
#
# The worker that your plugins should create and work
with
worker.list=ajp13

#
#-- DEFAULT ajp13 WORKER DEFINITION
--
#-
#

#
# Defining a worker named ajp13 and of type ajp13
# Note that the name and the type do not have to
match.
#
worker.ajp13.port=8009
worker.ajp13.host=localhost

#  End worker.properties **


 --- Jose Antonio Martinez [EMAIL PROTECTED] escribió:
 i have installed the isapi filter in the iis for
 redirection of jsp pages to a linux machine (it has
 a
 tomcat server).
 
 i have followed the documentation at:
 

http://members.ozemail.com.au/~lampante/howto/tomcat/iisnt/#6
 
 
 the array is green now , but when i try to view jsp
 samples, there is a problem: iis says it cant find
 the
 module !!!
 
 any idea?
 
 
 

___
 Yahoo! Messenger
 Nueva versión: Webcam, voz, y mucho más ¡Gratis! 
 Descárgalo ya desde http://messenger.yahoo.es
 
 --
 To unsubscribe, e-mail:  
 mailto:tomcat-user-unsubscribe;jakarta.apache.org
 For additional commands, e-mail:
 mailto:tomcat-user-help;jakarta.apache.org
  

___
Yahoo! Messenger
Nueva versión: Webcam, voz, y mucho más ¡Gratis! 
Descárgalo ya desde http://messenger.yahoo.es

--
To unsubscribe, e-mail:   mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org

Re: iis redirection to linux tomcat machine

[Jose Antonio Martinez]

sorry, here it is:

[Fri Nov 15 12:45:40 2002]  [jk_isapi_plugin.c (696)]:
HttpFilterProc started
[Fri Nov 15 12:45:40 2002]  [jk_isapi_plugin.c (759)]:
In HttpFilterProc Virtual Host redirection of
/www.domwindows.com/examples/
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(460)]: Into jk_uri_worker_map_t::map_uri_to_worker
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(477)]: Attempting to map URI
'/www.domwindows.com/examples/'
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(599)]: jk_uri_worker_map_t::map_uri_to_worker, done
without a match
[Fri Nov 15 12:45:40 2002]  [jk_isapi_plugin.c (765)]:
In HttpFilterProc test Default redirection of
/examples/
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(460)]: Into jk_uri_worker_map_t::map_uri_to_worker
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(477)]: Attempting to map URI '/examples/'
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(502)]: jk_uri_worker_map_t::map_uri_to_worker, Found
a context match remoto - /examples/
[Fri Nov 15 12:45:40 2002]  [jk_isapi_plugin.c (775)]:
HttpFilterProc [/examples/] is a servlet url - should
redirect to remoto
[Fri Nov 15 12:45:40 2002]  [jk_isapi_plugin.c (838)]:
HttpFilterProc check if [/examples/] is points to the
web-inf directory
[Fri Nov 15 12:45:40 2002]  [jk_isapi_plugin.c (696)]:
HttpFilterProc started
[Fri Nov 15 12:45:40 2002]  [jk_isapi_plugin.c (759)]:
In HttpFilterProc Virtual Host redirection of
/www.domwindows.com/jakarta/isapi_redirect.dll
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(460)]: Into jk_uri_worker_map_t::map_uri_to_worker
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(477)]: Attempting to map URI
'/www.domwindows.com/jakarta/isapi_redirect.dll'
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(599)]: jk_uri_worker_map_t::map_uri_to_worker, done
without a match
[Fri Nov 15 12:45:40 2002]  [jk_isapi_plugin.c (765)]:
In HttpFilterProc test Default redirection of
/jakarta/isapi_redirect.dll
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(460)]: Into jk_uri_worker_map_t::map_uri_to_worker
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(477)]: Attempting to map URI
'/jakarta/isapi_redirect.dll'
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(599)]: jk_uri_worker_map_t::map_uri_to_worker, done
without a match
[Fri Nov 15 12:45:40 2002]  [jk_isapi_plugin.c (829)]:
HttpFilterProc [/jakarta/isapi_redirect.dll] is not a
servlet url
[Fri Nov 15 12:45:40 2002]  [jk_isapi_plugin.c (838)]:
HttpFilterProc check if [/jakarta/isapi_redirect.dll]
is points to the web-inf directory


 --- Jose Antonio Martinez [EMAIL PROTECTED] escribió:
 here is the redirector isapi log:
 
 #  Begin worker.properties
 **
 worker.ajp13.type=ajp13
 
 #
 # Specifies the load balance factor when used with
 # a load balancing worker.
 # Note:
 #   lbfactor must be  0
 #   Low lbfactor means less work done by the
 worker.
 worker.ajp13.lbfactor=1
 
 #
 # Specify the size of the open connection cache.
 #worker.ajp13.cachesize
 
 #
 #-- DEFAULT LOAD BALANCER WORKER DEFINITION
 --

#-
 #
 
 #
 # The loadbalancer (type lb) worker perform weighted
 round-robin
 # load balancing with sticky sessions.
 # Note:
 #   If a worker dies, the load balancer will
 check its state
 #once in a while. Until then all work is
 redirected to peer
 #worker.
 worker.loadbalancer.type=lb
 worker.loadbalancer.balanced_workers=ajp13
 
 #
 # worker.tomcat_home should point to the location
 where you
 # installed tomcat. This is where you have your
 conf,
 webapps and lib
 # directories.
 #
 worker.tomcat_home=C:\jakarta-tomcat-4.0.1
 
 #
 # worker.java_home should point to your Java
 installation. Normally
 # you should have a bin and lib directories beneath
 it.
 #
 worker.java_home=C:\jdk1.3.1
 
 #
 # You should configure your environment slash...
 ps=\
 on NT and / on UNIX
 # and maybe something different elsewhere.
 #
 ps=\
 
 #
 #-- ADVANCED MODE
 

#-
 #
 
 #
 #-- DEFAULT worker list
 --

#-
 #
 # The worker that your plugins should create and
 work
 with
 worker.list=ajp13
 
 #
 #-- DEFAULT ajp13 WORKER DEFINITION
 --

#-
 #
 
 #
 # Defining a worker named ajp13 and of type ajp13
 # Note that the name and the type do not have to
 match.
 #
 worker.ajp13.port=8009
 worker.ajp13.host=localhost
 
 #  End worker.properties **
 
 
  --- Jose Antonio Martinez [EMAIL PROTECTED]
 escribió:
  i have installed the isapi filter in the iis for
  redirection of jsp pages to a linux machine (it
 has
  a
  tomcat server).
  
  i have followed

Re: iis redirection to linux tomcat machine

[Jose Antonio Martinez]

sorry, here it is:

[Fri Nov 15 12:45:40 2002]  [jk_isapi_plugin.c (696)]:
HttpFilterProc started
[Fri Nov 15 12:45:40 2002]  [jk_isapi_plugin.c (759)]:
In HttpFilterProc Virtual Host redirection of
/www.domwindows.com/examples/
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(460)]: Into jk_uri_worker_map_t::map_uri_to_worker
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(477)]: Attempting to map URI
'/www.domwindows.com/examples/'
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(599)]: jk_uri_worker_map_t::map_uri_to_worker, done
without a match
[Fri Nov 15 12:45:40 2002]  [jk_isapi_plugin.c (765)]:
In HttpFilterProc test Default redirection of
/examples/
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(460)]: Into jk_uri_worker_map_t::map_uri_to_worker
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(477)]: Attempting to map URI '/examples/'
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(502)]: jk_uri_worker_map_t::map_uri_to_worker, Found
a context match remoto - /examples/
[Fri Nov 15 12:45:40 2002]  [jk_isapi_plugin.c (775)]:
HttpFilterProc [/examples/] is a servlet url - should
redirect to remoto
[Fri Nov 15 12:45:40 2002]  [jk_isapi_plugin.c (838)]:
HttpFilterProc check if [/examples/] is points to the
web-inf directory
[Fri Nov 15 12:45:40 2002]  [jk_isapi_plugin.c (696)]:
HttpFilterProc started
[Fri Nov 15 12:45:40 2002]  [jk_isapi_plugin.c (759)]:
In HttpFilterProc Virtual Host redirection of
/www.domwindows.com/jakarta/isapi_redirect.dll
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(460)]: Into jk_uri_worker_map_t::map_uri_to_worker
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(477)]: Attempting to map URI
'/www.domwindows.com/jakarta/isapi_redirect.dll'
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(599)]: jk_uri_worker_map_t::map_uri_to_worker, done
without a match
[Fri Nov 15 12:45:40 2002]  [jk_isapi_plugin.c (765)]:
In HttpFilterProc test Default redirection of
/jakarta/isapi_redirect.dll
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(460)]: Into jk_uri_worker_map_t::map_uri_to_worker
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(477)]: Attempting to map URI
'/jakarta/isapi_redirect.dll'
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(599)]: jk_uri_worker_map_t::map_uri_to_worker, done
without a match
[Fri Nov 15 12:45:40 2002]  [jk_isapi_plugin.c (829)]:
HttpFilterProc [/jakarta/isapi_redirect.dll] is not a
servlet url
[Fri Nov 15 12:45:40 2002]  [jk_isapi_plugin.c (838)]:
HttpFilterProc check if [/jakarta/isapi_redirect.dll]
is points to the web-inf directory


 --- Jose Antonio Martinez [EMAIL PROTECTED] escribió:
 here is the redirector isapi log:
 
 #  Begin worker.properties
 **
 worker.ajp13.type=ajp13
 
 #
 # Specifies the load balance factor when used with
 # a load balancing worker.
 # Note:
 #   lbfactor must be  0
 #   Low lbfactor means less work done by the
 worker.
 worker.ajp13.lbfactor=1
 
 #
 # Specify the size of the open connection cache.
 #worker.ajp13.cachesize
 
 #
 #-- DEFAULT LOAD BALANCER WORKER DEFINITION
 --

#-
 #
 
 #
 # The loadbalancer (type lb) worker perform weighted
 round-robin
 # load balancing with sticky sessions.
 # Note:
 #   If a worker dies, the load balancer will
 check its state
 #once in a while. Until then all work is
 redirected to peer
 #worker.
 worker.loadbalancer.type=lb
 worker.loadbalancer.balanced_workers=ajp13
 
 #
 # worker.tomcat_home should point to the location
 where you
 # installed tomcat. This is where you have your
 conf,
 webapps and lib
 # directories.
 #
 worker.tomcat_home=C:\jakarta-tomcat-4.0.1
 
 #
 # worker.java_home should point to your Java
 installation. Normally
 # you should have a bin and lib directories beneath
 it.
 #
 worker.java_home=C:\jdk1.3.1
 
 #
 # You should configure your environment slash...
 ps=\
 on NT and / on UNIX
 # and maybe something different elsewhere.
 #
 ps=\
 
 #
 #-- ADVANCED MODE
 

#-
 #
 
 #
 #-- DEFAULT worker list
 --

#-
 #
 # The worker that your plugins should create and
 work
 with
 worker.list=ajp13
 
 #
 #-- DEFAULT ajp13 WORKER DEFINITION
 --

#-
 #
 
 #
 # Defining a worker named ajp13 and of type ajp13
 # Note that the name and the type do not have to
 match.
 #
 worker.ajp13.port=8009
 worker.ajp13.host=localhost
 
 #  End worker.properties **
 
 
  --- Jose Antonio Martinez [EMAIL PROTECTED]
 escribió:
  i have installed the isapi filter in the iis for
  redirection of jsp pages to a linux machine (it
 has
  a
  tomcat server).
  
  i have followed

Re: iis redirection to linux tomcat machine

[Jose Antonio Martinez]

sorry, here it is:

[Fri Nov 15 12:45:40 2002]  [jk_isapi_plugin.c (696)]:
HttpFilterProc started
[Fri Nov 15 12:45:40 2002]  [jk_isapi_plugin.c (759)]:
In HttpFilterProc Virtual Host redirection of
/www.domwindows.com/examples/
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(460)]: Into jk_uri_worker_map_t::map_uri_to_worker
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(477)]: Attempting to map URI
'/www.domwindows.com/examples/'
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(599)]: jk_uri_worker_map_t::map_uri_to_worker, done
without a match
[Fri Nov 15 12:45:40 2002]  [jk_isapi_plugin.c (765)]:
In HttpFilterProc test Default redirection of
/examples/
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(460)]: Into jk_uri_worker_map_t::map_uri_to_worker
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(477)]: Attempting to map URI '/examples/'
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(502)]: jk_uri_worker_map_t::map_uri_to_worker, Found
a context match remoto - /examples/
[Fri Nov 15 12:45:40 2002]  [jk_isapi_plugin.c (775)]:
HttpFilterProc [/examples/] is a servlet url - should
redirect to remoto
[Fri Nov 15 12:45:40 2002]  [jk_isapi_plugin.c (838)]:
HttpFilterProc check if [/examples/] is points to the
web-inf directory
[Fri Nov 15 12:45:40 2002]  [jk_isapi_plugin.c (696)]:
HttpFilterProc started
[Fri Nov 15 12:45:40 2002]  [jk_isapi_plugin.c (759)]:
In HttpFilterProc Virtual Host redirection of
/www.domwindows.com/jakarta/isapi_redirect.dll
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(460)]: Into jk_uri_worker_map_t::map_uri_to_worker
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(477)]: Attempting to map URI
'/www.domwindows.com/jakarta/isapi_redirect.dll'
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(599)]: jk_uri_worker_map_t::map_uri_to_worker, done
without a match
[Fri Nov 15 12:45:40 2002]  [jk_isapi_plugin.c (765)]:
In HttpFilterProc test Default redirection of
/jakarta/isapi_redirect.dll
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(460)]: Into jk_uri_worker_map_t::map_uri_to_worker
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(477)]: Attempting to map URI
'/jakarta/isapi_redirect.dll'
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(599)]: jk_uri_worker_map_t::map_uri_to_worker, done
without a match
[Fri Nov 15 12:45:40 2002]  [jk_isapi_plugin.c (829)]:
HttpFilterProc [/jakarta/isapi_redirect.dll] is not a
servlet url
[Fri Nov 15 12:45:40 2002]  [jk_isapi_plugin.c (838)]:
HttpFilterProc check if [/jakarta/isapi_redirect.dll]
is points to the web-inf directory


 --- Jose Antonio Martinez [EMAIL PROTECTED] escribió:
 here is the redirector isapi log:
 
 #  Begin worker.properties
 **
 worker.ajp13.type=ajp13
 
 #
 # Specifies the load balance factor when used with
 # a load balancing worker.
 # Note:
 #   lbfactor must be  0
 #   Low lbfactor means less work done by the
 worker.
 worker.ajp13.lbfactor=1
 
 #
 # Specify the size of the open connection cache.
 #worker.ajp13.cachesize
 
 #
 #-- DEFAULT LOAD BALANCER WORKER DEFINITION
 --

#-
 #
 
 #
 # The loadbalancer (type lb) worker perform weighted
 round-robin
 # load balancing with sticky sessions.
 # Note:
 #   If a worker dies, the load balancer will
 check its state
 #once in a while. Until then all work is
 redirected to peer
 #worker.
 worker.loadbalancer.type=lb
 worker.loadbalancer.balanced_workers=ajp13
 
 #
 # worker.tomcat_home should point to the location
 where you
 # installed tomcat. This is where you have your
 conf,
 webapps and lib
 # directories.
 #
 worker.tomcat_home=C:\jakarta-tomcat-4.0.1
 
 #
 # worker.java_home should point to your Java
 installation. Normally
 # you should have a bin and lib directories beneath
 it.
 #
 worker.java_home=C:\jdk1.3.1
 
 #
 # You should configure your environment slash...
 ps=\
 on NT and / on UNIX
 # and maybe something different elsewhere.
 #
 ps=\
 
 #
 #-- ADVANCED MODE
 

#-
 #
 
 #
 #-- DEFAULT worker list
 --

#-
 #
 # The worker that your plugins should create and
 work
 with
 worker.list=ajp13
 
 #
 #-- DEFAULT ajp13 WORKER DEFINITION
 --

#-
 #
 
 #
 # Defining a worker named ajp13 and of type ajp13
 # Note that the name and the type do not have to
 match.
 #
 worker.ajp13.port=8009
 worker.ajp13.host=localhost
 
 #  End worker.properties **
 
 
  --- Jose Antonio Martinez [EMAIL PROTECTED]
 escribió:
  i have installed the isapi filter in the iis for
  redirection of jsp pages to a linux machine (it
 has
  a
  tomcat server).
  
  i have followed

RE: iis redirection to linux tomcat machine

[Turner, John]

First of all, you aren't going to redirect *anything* to a Linux-based
Tomcat server, from an IIS web server, with worker.ajp13.host = localhost.
You need to change host to equal the FQDN or IP address of the Linux
server.

John

 -Original Message-
 From: Jose Antonio Martinez [mailto:lfbbes;yahoo.es]
 Sent: Friday, November 15, 2002 6:47 AM
 To: Tomcat Users List
 Subject: Re: iis redirection to linux tomcat machine
 
 
 here is the redirector isapi log:
 
 #-- DEFAULT ajp13 WORKER DEFINITION
 --
 #-
 #
 
 #
 # Defining a worker named ajp13 and of type ajp13
 # Note that the name and the type do not have to
 match.
 #
 worker.ajp13.port=8009
 worker.ajp13.host=localhost
 
 #  End worker.properties **
 
 
  --- Jose Antonio Martinez [EMAIL PROTECTED] escribió:
  i have installed the isapi filter in the iis for
  redirection of jsp pages to a linux machine (it has
  a
  tomcat server).
  
  i have followed the documentation at:
  
 
 http://members.ozemail.com.au/~lampante/howto/tomcat/iisnt/#6
  
  
  the array is green now , but when i try to view jsp
  samples, there is a problem: iis says it cant find
  the
  module !!!
  
  any idea?
  
  
  
 
 ___
  Yahoo! Messenger
  Nueva versión: Webcam, voz, y mucho más ¡Gratis! 
  Descárgalo ya desde http://messenger.yahoo.es
  
  --
  To unsubscribe, e-mail:  
  mailto:tomcat-user-unsubscribe;jakarta.apache.org
  For additional commands, e-mail:
  mailto:tomcat-user-help;jakarta.apache.org
   
 
 ___
 Yahoo! Messenger
 Nueva versión: Webcam, voz, y mucho más ¡Gratis! 
 Descárgalo ya desde http://messenger.yahoo.es
 
 --
 To unsubscribe, e-mail:   
mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:tomcat-user-help;jakarta.apache.org

--
To unsubscribe, e-mail:   mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org

RE: iis redirection to linux tomcat machine

[Jose Antonio Martinez]

sorry, i copy a wrong file, this is the right one:


#
# worker.tomcat_home should point to the location
where you
# installed tomcat. This is where you have your conf,
webapps and lib
# directories.
#
worker.tomcat_home=C:\jakarta-tomcat

#
# worker.java_home should point to your Java
installation. Normally
# you should have a bin and lib directories beneath
it.
#
worker.java_home=C:\jakarta-tomcat


ps=\

worker.list=remoto



worker.remoto.port=8009
worker.remoto.host=192.168.65.193
worker.remoto.type=ajp13



 --- Turner, John [EMAIL PROTECTED] escribió:  
 First of all, you aren't going to redirect
 *anything* to a Linux-based
 Tomcat server, from an IIS web server, with
 worker.ajp13.host = localhost.
 You need to change host to equal the FQDN or IP
 address of the Linux
 server.
 
 John
 
  -Original Message-
  From: Jose Antonio Martinez
 [mailto:lfbbes;yahoo.es]
  Sent: Friday, November 15, 2002 6:47 AM
  To: Tomcat Users List
  Subject: Re: iis redirection to linux tomcat
 machine
  
  
  here is the redirector isapi log:
  
  #-- DEFAULT ajp13 WORKER DEFINITION
  --
 

#-
  #
  
  #
  # Defining a worker named ajp13 and of type ajp13
  # Note that the name and the type do not have to
  match.
  #
  worker.ajp13.port=8009
  worker.ajp13.host=localhost
  
  #  End worker.properties
 **
  
  
   --- Jose Antonio Martinez [EMAIL PROTECTED]
 escribió:
   i have installed the isapi filter in the iis for
   redirection of jsp pages to a linux machine (it
 has
   a
   tomcat server).
   
   i have followed the documentation at:
   
  
 

http://members.ozemail.com.au/~lampante/howto/tomcat/iisnt/#6
   
   
   the array is green now , but when i try to view
 jsp
   samples, there is a problem: iis says it cant
 find
   the
   module !!!
   
   any idea?
   
   
   
  
 

___
   Yahoo! Messenger
   Nueva versión: Webcam, voz, y mucho más ¡Gratis!
 
   Descárgalo ya desde http://messenger.yahoo.es
   
   --
   To unsubscribe, e-mail:  
  
 mailto:tomcat-user-unsubscribe;jakarta.apache.org
   For additional commands, e-mail:
   mailto:tomcat-user-help;jakarta.apache.org

  
 

___
  Yahoo! Messenger
  Nueva versión: Webcam, voz, y mucho más ¡Gratis! 
  Descárgalo ya desde http://messenger.yahoo.es
  
  --
  To unsubscribe, e-mail:   
 mailto:tomcat-user-unsubscribe;jakarta.apache.org
 For additional commands, e-mail:
 mailto:tomcat-user-help;jakarta.apache.org
 
 --
 To unsubscribe, e-mail:  
 mailto:tomcat-user-unsubscribe;jakarta.apache.org
 For additional commands, e-mail:
 mailto:tomcat-user-help;jakarta.apache.org
  

___
Yahoo! Messenger
Nueva versión: Webcam, voz, y mucho más ¡Gratis! 
Descárgalo ya desde http://messenger.yahoo.es

--
To unsubscribe, e-mail:   mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org

RE: iis redirection to linux tomcat machine

[Turner, John]

From the log you posted:

(477)]: Attempting to map URI
'/www.domwindows.com/jakarta/isapi_redirect.dll'
[Fri Nov 15 12:45:40 2002]  [jk_uri_worker_map.c
(599)]: jk_uri_worker_map_t::map_uri_to_worker, done
without a match

Does your mapping file have an entry that would satisfy the URI?  What are
the contents of uriworkermap.properties?  I don't use IIS, but it looks to
me like you're missing a piece or two.

John


 -Original Message-
 From: Jose Antonio Martinez [mailto:lfbbes;yahoo.es]
 Sent: Friday, November 15, 2002 8:16 AM
 To: Tomcat Users List
 Subject: RE: iis redirection to linux tomcat machine
 
 
 sorry, i copy a wrong file, this is the right one:
 
 
 #
 # worker.tomcat_home should point to the location
 where you
 # installed tomcat. This is where you have your conf,
 webapps and lib
 # directories.
 #
 worker.tomcat_home=C:\jakarta-tomcat
 
 #
 # worker.java_home should point to your Java
 installation. Normally
 # you should have a bin and lib directories beneath
 it.
 #
 worker.java_home=C:\jakarta-tomcat
 
 
 ps=\
 
 worker.list=remoto
 
 
 
 worker.remoto.port=8009
 worker.remoto.host=192.168.65.193
 worker.remoto.type=ajp13
 

--
To unsubscribe, e-mail:   mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org

Re: Port redirection on Tomcat standalone

[Torsten Fohrer]

which redirectPort have you stay in your normal 8080 tomcat connector config?


On Wednesday 13 November 2002 23:57, Michal Kreglewski wrote:
 Hi,

 I've got a problem with port redirection on Tomcat 4.1.12 standalone. I've
 enabled SSL in server.xml and it works fine. But then I put the following
 in web.xml:

 security-constraint
   web-resource-collection
 web-resource-nameMy Servlet/web-resource-name
 url-pattern/myServlet/url-pattern
   /web-resource-collection
   auth-constraint
 role-namemyRole/role-name
   /auth-constraint
   user-data-constraint
 transport-guaranteeCONFIDENTIAL/transport-guarantee
   /user-data-constraint
 /security-constraint

 login-config
   auth-methodFORM/auth-method
   realm-nameDyplom application/realm-name
   form-login-config
 form-login-page/login.jsp/form-login-page
 form-error-page/error.jsp/form-error-page
   /form-login-config
 /login-config

 security-role
   role-namemyRole/role-name
 /security-role

 And now I expect that invoking http://localhost:8080/myApp/myServlet will
 redirect me to login.jsp page over HTTPS. And that works ok, but only if
 Tomcat works on 80 and 443 ports. Otherwise my browser (IE 6.0) only asks
 me to accept the server certificate and then it can't connect to the
 server.

 Is there a way to make it work on other ports (for example on default 8080
 and 8443)?

 Mind, that when I ommit auth-constraint tag it works as it should -
 MyServlet is invoked over HTTPS.

 Thanks for any help.
 Michal


 --
 To unsubscribe, e-mail:  
 mailto:[EMAIL PROTECTED] For additional
 commands, e-mail: mailto:[EMAIL PROTECTED]


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Port redirection on Tomcat standalone

[Michal Kreglewski]

Hi,

I've got a problem with port redirection on Tomcat 4.1.12 standalone. I've
enabled SSL in server.xml and it works fine. But then I put the following in
web.xml:

security-constraint
  web-resource-collection
web-resource-nameMy Servlet/web-resource-name
url-pattern/myServlet/url-pattern
  /web-resource-collection
  auth-constraint
role-namemyRole/role-name
  /auth-constraint
  user-data-constraint
transport-guaranteeCONFIDENTIAL/transport-guarantee
  /user-data-constraint
/security-constraint

login-config
  auth-methodFORM/auth-method
  realm-nameDyplom application/realm-name
  form-login-config
form-login-page/login.jsp/form-login-page
form-error-page/error.jsp/form-error-page
  /form-login-config
/login-config

security-role
  role-namemyRole/role-name
/security-role

And now I expect that invoking http://localhost:8080/myApp/myServlet will
redirect me to login.jsp page over HTTPS. And that works ok, but only if
Tomcat works on 80 and 443 ports. Otherwise my browser (IE 6.0) only asks me
to accept the server certificate and then it can't connect to the server.

Is there a way to make it work on other ports (for example on default 8080
and 8443)?

Mind, that when I ommit auth-constraint tag it works as it should -
MyServlet is invoked over HTTPS.

Thanks for any help.
Michal


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: Port redirection on Tomcat standalone

[Michal Kreglewski]

Everything works when when I do like this:

Connector className=org.apache.catalina.connector.http.HttpConnector
port=80 minProcessors=5 maxProcessors=75 enableLookups=true
redirectPort=443 acceptCount=10 debug=0 connectionTimeout=6/
Connector className=org.apache.catalina.connector.http.HttpConnector
port=443 minProcessors=5 maxProcessors=75 enableLookups=true
acceptCount=10 debug=0 scheme=https secure=true
  Factory className=org.apache.catalina.net.SSLServerSocketFactory
clientAuth=false protocol=TLS/
/Connector


It doesn't when I do like this:

Connector className=org.apache.catalina.connector.http.HttpConnector
port=8080 minProcessors=5 maxProcessors=75 enableLookups=true
redirectPort=8443 acceptCount=10 debug=0 connectionTimeout=6/
Connector className=org.apache.catalina.connector.http.HttpConnector
port=8443 minProcessors=5 maxProcessors=75 enableLookups=true
acceptCount=10 debug=0 scheme=https secure=true
  Factory className=org.apache.catalina.net.SSLServerSocketFactory
clientAuth=false protocol=TLS/
/Connector

Regards
Michal


- Original Message -
From: Torsten Fohrer [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Cc: Michal Kreglewski [EMAIL PROTECTED]
Sent: Thursday, November 14, 2002 12:08 AM
Subject: Re: Port redirection on Tomcat standalone



 which redirectPort have you stay in your normal 8080 tomcat connector
config?


 On Wednesday 13 November 2002 23:57, Michal Kreglewski wrote:
  Hi,
 
  I've got a problem with port redirection on Tomcat 4.1.12 standalone.
I've
  enabled SSL in server.xml and it works fine. But then I put the
following
  in web.xml:
 
  security-constraint
web-resource-collection
  web-resource-nameMy Servlet/web-resource-name
  url-pattern/myServlet/url-pattern
/web-resource-collection
auth-constraint
  role-namemyRole/role-name
/auth-constraint
user-data-constraint
  transport-guaranteeCONFIDENTIAL/transport-guarantee
/user-data-constraint
  /security-constraint
 
  login-config
auth-methodFORM/auth-method
realm-nameDyplom application/realm-name
form-login-config
  form-login-page/login.jsp/form-login-page
  form-error-page/error.jsp/form-error-page
/form-login-config
  /login-config
 
  security-role
role-namemyRole/role-name
  /security-role
 
  And now I expect that invoking http://localhost:8080/myApp/myServlet
will
  redirect me to login.jsp page over HTTPS. And that works ok, but only if
  Tomcat works on 80 and 443 ports. Otherwise my browser (IE 6.0) only
asks
  me to accept the server certificate and then it can't connect to the
  server.
 
  Is there a way to make it work on other ports (for example on default
8080
  and 8443)?
 
  Mind, that when I ommit auth-constraint tag it works as it should -
  MyServlet is invoked over HTTPS.
 
  Thanks for any help.
  Michal
 
 
  --
  To unsubscribe, e-mail:
  mailto:[EMAIL PROTECTED] For additional
  commands, e-mail: mailto:[EMAIL PROTECTED]


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

RE: Port redirection on Tomcat standalone

[Turner, John]

 
That's because it's your browser making the second request, not you typing
in an extra 8443 on the end, and your browser only knows SSL on port 443.

John

-Original Message-
From: Michal Kreglewski
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: 11/13/02 6:16 PM
Subject: Re: Port redirection on Tomcat standalone

Everything works when when I do like this:

Connector className=org.apache.catalina.connector.http.HttpConnector
port=80 minProcessors=5 maxProcessors=75 enableLookups=true
redirectPort=443 acceptCount=10 debug=0
connectionTimeout=6/
Connector className=org.apache.catalina.connector.http.HttpConnector
port=443 minProcessors=5 maxProcessors=75 enableLookups=true
acceptCount=10 debug=0 scheme=https secure=true
  Factory className=org.apache.catalina.net.SSLServerSocketFactory
clientAuth=false protocol=TLS/
/Connector


It doesn't when I do like this:

Connector className=org.apache.catalina.connector.http.HttpConnector
port=8080 minProcessors=5 maxProcessors=75 enableLookups=true
redirectPort=8443 acceptCount=10 debug=0
connectionTimeout=6/
Connector className=org.apache.catalina.connector.http.HttpConnector
port=8443 minProcessors=5 maxProcessors=75 enableLookups=true
acceptCount=10 debug=0 scheme=https secure=true
  Factory className=org.apache.catalina.net.SSLServerSocketFactory
clientAuth=false protocol=TLS/
/Connector

Regards
Michal


- Original Message -
From: Torsten Fohrer [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Cc: Michal Kreglewski [EMAIL PROTECTED]
Sent: Thursday, November 14, 2002 12:08 AM
Subject: Re: Port redirection on Tomcat standalone



 which redirectPort have you stay in your normal 8080 tomcat connector
config?


 On Wednesday 13 November 2002 23:57, Michal Kreglewski wrote:
  Hi,
 
  I've got a problem with port redirection on Tomcat 4.1.12
standalone.
I've
  enabled SSL in server.xml and it works fine. But then I put the
following
  in web.xml:
 
  security-constraint
web-resource-collection
  web-resource-nameMy Servlet/web-resource-name
  url-pattern/myServlet/url-pattern
/web-resource-collection
auth-constraint
  role-namemyRole/role-name
/auth-constraint
user-data-constraint
  transport-guaranteeCONFIDENTIAL/transport-guarantee
/user-data-constraint
  /security-constraint
 
  login-config
auth-methodFORM/auth-method
realm-nameDyplom application/realm-name
form-login-config
  form-login-page/login.jsp/form-login-page
  form-error-page/error.jsp/form-error-page
/form-login-config
  /login-config
 
  security-role
role-namemyRole/role-name
  /security-role
 
  And now I expect that invoking http://localhost:8080/myApp/myServlet
will
  redirect me to login.jsp page over HTTPS. And that works ok, but
only if
  Tomcat works on 80 and 443 ports. Otherwise my browser (IE 6.0) only
asks
  me to accept the server certificate and then it can't connect to the
  server.
 
  Is there a way to make it work on other ports (for example on
default
8080
  and 8443)?
 
  Mind, that when I ommit auth-constraint tag it works as it should
-
  MyServlet is invoked over HTTPS.
 
  Thanks for any help.
  Michal
 
 
  --
  To unsubscribe, e-mail:
  mailto:[EMAIL PROTECTED] For additional
  commands, e-mail: mailto:[EMAIL PROTECTED]


--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Servlet redirection problem

[Tam, Michael]

Hi all,

I am running Tomcat 4.1.12 + Apache 1.3.27 with mod_webapp on Win2k pro
machine.  I have a doPost() in a servlet which at the end would redirects to
a url with a query string (e.g.
newurl?VALUE1=abcVALUE2=def) by calling respond.sendRedirect().   

The servlet did redirect to the target url but the query string is
scrambled.  From the given example, my resulting url becomes ---
newurl?value1=abcvalue2=dVAULE1=abcVALUE2=def  [Please pay attention to
the case the parameters].  It seems like I have a addition query string
(with incomplete value) attach to the url before my original url.  


Any input would be appreciated. Thank you.

Regards,
Michael



---
Michael Tam - NFI Database Developer   Natural
Resources Canada
[EMAIL PROTECTED] Pacific Forestry
Center
Phone: (250) 363-8074   506 West Burnside
Road
Fax: (250) 363-0775 Victoria, BC
V8Z 1M5




--
To unsubscribe, e-mail:   mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org

RE: Servlet redirection problem

[Mike Jackson]

While redirect?  You could do the parameters as request attributes and use a
dispatcher...

--mikej
-=-
mike jackson
[EMAIL PROTECTED]

 -Original Message-
 From: Tam, Michael [mailto:mtam;PFC.Forestry.CA]
 Sent: Friday, November 01, 2002 4:13 PM
 To: Tomcat UserList (E-mail)
 Subject: Servlet redirection problem


 Hi all,

 I am running Tomcat 4.1.12 + Apache 1.3.27 with mod_webapp on Win2k pro
 machine.  I have a doPost() in a servlet which at the end would
 redirects to
 a url with a query string (e.g.
 newurl?VALUE1=abcVALUE2=def) by calling respond.sendRedirect().

 The servlet did redirect to the target url but the query string is
 scrambled.  From the given example, my resulting url becomes ---
 newurl?value1=abcvalue2=dVAULE1=abcVALUE2=def  [Please pay attention to
 the case the parameters].  It seems like I have a addition query string
 (with incomplete value) attach to the url before my original url.


 Any input would be appreciated. Thank you.

 Regards,
 Michael


 --
 --
 ---
 Michael Tam - NFI Database Developer   Natural
 Resources Canada
 [EMAIL PROTECTED]   Pacific Forestry
 Center
 Phone: (250) 363-8074 506
 West Burnside
 Road
 Fax: (250) 363-0775   Victoria, BC
 V8Z 1M5




 --
 To unsubscribe, e-mail:
mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:tomcat-user-help;jakarta.apache.org



--
To unsubscribe, e-mail:   mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org

RE: Servlet redirection problem

[Mike Jackson]

Oops, I ment to say Why redirect...

--mikej
-=-
mike jackson
[EMAIL PROTECTED]

 -Original Message-
 From: Mike Jackson [mailto:mjackson;cdi-hq.com]
 Sent: Friday, November 01, 2002 4:24 PM
 To: Tomcat Users List
 Subject: RE: Servlet redirection problem


 While redirect?  You could do the parameters as request
 attributes and use a
 dispatcher...

 --mikej
 -=-
 mike jackson
 [EMAIL PROTECTED]

  -Original Message-
  From: Tam, Michael [mailto:mtam;PFC.Forestry.CA]
  Sent: Friday, November 01, 2002 4:13 PM
  To: Tomcat UserList (E-mail)
  Subject: Servlet redirection problem
 
 
  Hi all,
 
  I am running Tomcat 4.1.12 + Apache 1.3.27 with mod_webapp on Win2k pro
  machine.  I have a doPost() in a servlet which at the end would
  redirects to
  a url with a query string (e.g.
  newurl?VALUE1=abcVALUE2=def) by calling respond.sendRedirect().
 
  The servlet did redirect to the target url but the query string is
  scrambled.  From the given example, my resulting url becomes ---
  newurl?value1=abcvalue2=dVAULE1=abcVALUE2=def  [Please pay
 attention to
  the case the parameters].  It seems like I have a addition query string
  (with incomplete value) attach to the url before my original url.
 
 
  Any input would be appreciated. Thank you.
 
  Regards,
  Michael
 
 
  --
  --
  ---
  Michael Tam - NFI Database Developer   Natural
  Resources Canada
  [EMAIL PROTECTED] Pacific Forestry
  Center
  Phone: (250) 363-8074   506
  West Burnside
  Road
  Fax: (250) 363-0775 Victoria, BC
  V8Z 1M5
 
 
 
 
  --
  To unsubscribe, e-mail:
 mailto:tomcat-user-unsubscribe;jakarta.apache.org
 For additional commands, e-mail:
 mailto:tomcat-user-help;jakarta.apache.org



 --
 To unsubscribe, e-mail:
mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:tomcat-user-help;jakarta.apache.org



--
To unsubscribe, e-mail:   mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org

Re: Servlet redirection problem

[Bill Barker]

Alternatively, read the README file, and realize that mod_webapp is not
currently supported on Windows (or for Apache2 with MPM != prefork).

Tam, Michael [EMAIL PROTECTED] wrote in message
news:E3725E2B7548D51192090002A534A18A01730E07;s2-vic-r1.nrn.nrcan.gc.ca...
 Hi all,

 I am running Tomcat 4.1.12 + Apache 1.3.27 with mod_webapp on Win2k pro
 machine.  I have a doPost() in a servlet which at the end would redirects
to
 a url with a query string (e.g.
 newurl?VALUE1=abcVALUE2=def) by calling respond.sendRedirect().

 The servlet did redirect to the target url but the query string is
 scrambled.  From the given example, my resulting url becomes ---
 newurl?value1=abcvalue2=dVAULE1=abcVALUE2=def  [Please pay attention to
 the case the parameters].  It seems like I have a addition query string
 (with incomplete value) attach to the url before my original url.


 Any input would be appreciated. Thank you.

 Regards,
 Michael


 --
--
 ---
 Michael Tam - NFI Database Developer   Natural
 Resources Canada
 [EMAIL PROTECTED]Pacific Forestry
 Center
 Phone: (250) 363-8074 506 West Burnside
 Road
 Fax: (250) 363-0775 Victoria, BC
 V8Z 1M5





--
To unsubscribe, e-mail:   mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org

Apache+SSL+Tomcat - servlet redirection problem

[Bala]

I configurd Apache 1.3.9 , modSSL, openSSL and TOMCAT
3.2.3.
For http , it is working fine. For Https, In one of my
servlet ,
I redirected the request to other servlet. To form the
redirect 
URL i used HttpServletRequest.getScheme(); It always
returns 
http instead of https. I am getting following
error msg.

Bad Request

Your browser sent a request that this server could not
understand.

Reason: You're speaking plain HTTP to an SSL-enabled
server port.
Instead use the HTTPS scheme to access this URL,
please.

 Hint: https://someurl
-
SSL works fine, except the redirection part.
How to make things work?. Please give me an idea?

Regards
Balachandar



=
One important key to success is self-confidence. 
 An important key to self-confidence is preparation

__
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/

--
To unsubscribe, e-mail:   mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org

Re: Apache+SSL+Tomcat - servlet redirection problem

[Anitha K Rao]

Hello,

   Check out this site. May be this would help you.
http://enterprise.netscape.com/docs/enterprise/60/servlet/serv.htm


- Original Message -
From: Bala [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Sent: Wednesday, October 30, 2002 10:38 AM
Subject: Apache+SSL+Tomcat - servlet redirection problem


 I configurd Apache 1.3.9 , modSSL, openSSL and TOMCAT
 3.2.3.
 For http , it is working fine. For Https, In one of my
 servlet ,
 I redirected the request to other servlet. To form the
 redirect
 URL i used HttpServletRequest.getScheme(); It always
 returns
 http instead of https. I am getting following
 error msg.
 
 Bad Request

 Your browser sent a request that this server could not
 understand.

 Reason: You're speaking plain HTTP to an SSL-enabled
 server port.
 Instead use the HTTPS scheme to access this URL,
 please.

  Hint: https://someurl
 -
 SSL works fine, except the redirection part.
 How to make things work?. Please give me an idea?

 Regards
 Balachandar



 =
 One important key to success is self-confidence.
  An important key to self-confidence is preparation

 __
 Do you Yahoo!?
 HotJobs - Search new jobs daily now
 http://hotjobs.yahoo.com/

 --
 To unsubscribe, e-mail:
mailto:tomcat-user-unsubscribe;jakarta.apache.org
 For additional commands, e-mail:
mailto:tomcat-user-help;jakarta.apache.org




--
To unsubscribe, e-mail:   mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org

Apache+SSL+Tomcat - servlet redirection problem

[Bala]

I configurd Apache 1.3.9 , modSSL, openSSL and TOMCAT
3.2.3.
For http , it is working fine. For Https, In one of my
servlet ,
I redirected the request to other servlet. To form the
redirect 
URL i used HttpServletRequest.getScheme(); It always
returns 
http instead of https. I am getting following
error msg.

Bad Request

Your browser sent a request that this server could not
understand.

Reason: You're speaking plain HTTP to an SSL-enabled
server port.
Instead use the HTTPS scheme to access this URL,
please.

 Hint: https://someurl
-
SSL works fine, except the redirection part.
How to make things work?. Please give me an idea?

Regards
Balachandar

=
One important key to success is self-confidence. 
 An important key to self-confidence is preparation

__
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/

--
To unsubscribe, e-mail:   mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org

Re: problem with session tracking and redirection http--- https

[Jon Eaves]

Henrik Bentel wrote:

One of my problems is that I can't find anything in the servlet or 
tomcat documentation that mentiones any of this behaviour. If there is 
any, please send me the link.


Hi Henrik,

I couldn't find anything specific in the Servlet Spec, but in general
it's just not a good idea, as you may as well not use https at all.
It's not just the servlet spec that you need to be aware of, but this
is a more general HTTP/HTTPS problem.

RFC2109 is not really clear on the topic, other than section 8.3 which
talks about Unexpected Cookie Sharing.  However there is an extension to
this RFC, RFC2965 Port Sensitive Cookies.

Basically, you can't guarantee that the browser is going to send back
the cookie if the ports are different



Also, since any time session tracking is used it can be picked up by 
someone, all use of https should stay strictly under https(ok, I'm over 
doing it). So basically if a webapp has any sensitive information, it 
should solely use https protocol for all transmissions, if using session 
tracking?

You're not over doing it.  If you want to provide some security or
protection of authentication then the entire session _must_ be
encrypted or you may as well not bother.



I don't see why the servlet container should force this behaviour.


You can do your own session tracking if you want to.  Just set your
own cookies and use that.  The servlet container provides a very
convenient way of doing it.  Of course, you'll have the same
transition problems that the inbuild session management has.



Shouldn't it be up to the developer to determine what is a security 
issue and not? Just like JSP doesn't neccesseraly force the separation 
of business logic and content, just allowing it, should the servlet 
container force a restrictive behaviour of session tracking?
A lot of web sites don't want the over head of sending everything over 
https. Only parts of it for secure user validation. But they still want 
session tracking.

They may do, but they're broken if they don't keep an authentication
session safe under ssl.  Of course the session tracking can be used
at different times for non crucial session tracking.



Just as a simple example:
So let's say you use the existence of an http session as a validation 
for a logged in user, but you don't store any vital information.
And you only allow http sessions to be created under https protocol to 
secure the submition of password. Beyond that point, no sensitive data 
is shared, so users can be redirected back to http protocol.

You really need to read up on how HTTP and the servlet spec says sessions
are done.  Basically HTTP is stateless and sessions are faked by
transferring chunks of data between the client and the server.  This may
be via cookies or URL rewriting.   For the sake of convenience, we'll use
the cookie method in the example, but this is _not_ necessarily the only
way that sessions may be tracked.

So, you login securely under username and password admin/secret and
those pieces of information are gone and lost forever.  However, to
maintain the session over the stateless protocol the server sets a
cookie in the browser SECRET_COOKIE=aaa56722derf.  Now, as you
transition to HTTP that piece of information is sent to the server
in plain text that anybody can read.

So, me being the evil wily hacker grabs that information, and sets a
cookie in my evil hacked mozilla browser which will allow me to set
arbitrary cookies and bingo, I'm now you.



With tomcat 4, the only way to use the same method would be to create a 
http seesion for every http request, then redirect to https, add some 
kind of validation flags in the session object, then redirect back. This 
to me is worse, as a DoS attack could force the servlet container to 
create a http session for every Request, really putting a strain on 
your container.

I can't possibly think of any circumstance where you would need to
perform such a contrived mechanism.  In fact, I can't even understand
what you're trying to do here.

[ snip of rest of post ]

--
Jon Eaves [EMAIL PROTECTED]
http://www.eaves.org/jon/


--
To unsubscribe, e-mail:   mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org

Re: problem with session tracking and redirection http--- https

[Maninder S Batth]

my 2 cents:

encrypting session information such as encrypted urls or  cookies dont 
buy anything. they can be sniffed , and sent back. or worse things can 
happen.  Security is not cheap so forget finding an inexpensive way. 
thats one big problem with open protocols, you know exactly where to 
get the information and the stucture of information. SSL seems to be the 
cheapest way of doing business online as of now.

Re: problem with session tracking and redirection http--- https

[Craig R. McClanahan]

On Sat, 19 Oct 2002, Henrik Bentel wrote:

 Date: Sat, 19 Oct 2002 19:08:35 +
 From: Henrik Bentel [EMAIL PROTECTED]
 Reply-To: Tomcat Users List [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Re: problem with session tracking and redirection http--- https

 One of my problems is that I can't find anything in the servlet or tomcat
 documentation that mentiones any of this behaviour. If there is any, please
 send me the link.


It's not specific to servlets at all ... it's a fundamental issue for
anything running across http/https that wants to do the equivalent of
sessions.

 Also, since any time session tracking is used it can be picked up by
 someone, all use of https should stay strictly under https(ok, I'm over
 doing it). So basically if a webapp has any sensitive information, it should
 solely use https protocol for all transmissions, if using session tracking?


Not necessarily.

Consider an ecommerce site.  You'd typically maintain the shopping cart as
some sort of collection in a session attribute.  You could easily make the
case that this information is not particularly sensitive (especially if
you haven't collected any personal identification information yet).  So,
it's quite reasonable to run this part of the app across http.

However, once you go to the checkout phase of the app, you should switch
to https for the screen that submits the credit card details and that sort
of thing, so that nobody can snoop that data as it's being transmitted.

However, you are not done yet.  Once a particular session has been
switched from http to https, it MUST contain logic to never accept a
subsequent request (for that session) from http again.  Otherwise, your
app is subject to attacks like repeatedly submitting the Purchase
Confirmation form again, and causing multiple orders to be submitted.

 I don't see why the servlet container should force this behaviour. Shouldn't
 it be up to the developer to determine what is a security issue and not?

The http-https transition is supported by the servlet spec (and by
Tomcat).  That's what the transport-guarantee element in a security
constraint is for.

The https-http transition is not supported because it is fundamentally
flawed, and it would be irresponsible for the container to allow naive
developers to unknowningly create vulnerable applications.

 Just like JSP doesn't neccesseraly force the separation of business logic
 and content, just allowing it, should the servlet container force a
 restrictive behaviour of session tracking?
 A lot of web sites don't want the over head of sending everything over
 https. Only parts of it for secure user validation. But they still want
 session tracking.

 Just as a simple example:
 So let's say you use the existence of an http session as a validation for a
 logged in user, but you don't store any vital information.
 And you only allow http sessions to be created under https protocol to
 secure the submition of password. Beyond that point, no sensitive data is
 shared, so users can be redirected back to http protocol.


No you *cannot* do this safely (from a security perspective).

The reason is that the session id *itself* is security sensitive
information (because you stored state information in the session that
login was successful).  Once you switch back into http, the session id is
transmitted in clear text, and is subject to hijacking.  Anyone on the
internet can submit requests using that session id, and the requsts will
be executed by your app as if they were submitted by the person who was
originally authenticated.

Developers who feel that it's sufficient to use https only for the login
screen, but want to use http for the rest of the session, are fooling
themselves that they have accomplished anything useful (from a security
perspective).

 With tomcat 4, the only way to use the same method would be to create a http
 seesion for every http request, then redirect to https, add some kind of
 validation flags in the session object, then redirect back. This to me is
 worse, as a DoS attack could force the servlet container to create a http
 session for every Request, really putting a strain on your container.

 The example probably isn't a good example for how a typical website enforces
 secure validation, but I just want to raise the point that the hole is
 still there, since sessions created under http are available in all schemes.
 It could just as easily be misused by a developer.


You are correct that the restriction I'm talking about doesn't deal with
DoS attacks based on causing lots of sessions to be created.  It deals
with a completely different issue.

Craig


--
To unsubscribe, e-mail:   mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org

Re: problem with session tracking and redirection http--- https

[Craig R. McClanahan]

On Fri, 18 Oct 2002, Maninder S Batth wrote:

 Date: Fri, 18 Oct 2002 20:11:31 -0700
 From: Maninder S Batth [EMAIL PROTECTED]
 Reply-To: Tomcat Users List [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Re: problem with session tracking and redirection http--- https

  if  session apis and request dispatchers are used for internal
 redirection, is there still any security hole??


No, but you can't switch from http to https (or from https to http) across
a RequestDispatcher.forward call.  The response will be sent on the same
protocol used to submit the request.

Craig

 Craig R. McClanahan wrote:

 On Fri, 18 Oct 2002, Henrik Bentel wrote:
 
 
 
 Date: Fri, 18 Oct 2002 23:07:17 +
 From: Henrik Bentel [EMAIL PROTECTED]
 Reply-To: Tomcat Users List [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Re: problem with session tracking and redirection http--- https
 
 
 
 yeah, I always encode the redirection URL.
 it's waird that it works if the session is created which under http, but not
 under https.
 
 bug maybe?
 
 
 
 
 Nope ... avoidance of a huge security hole.
 
 Once a session is accessed via https, it should never ever be allowed to
 be accessed from http again.  The reason for this is that the session id
 is transmitted in clear text, so anyone who can snoop the network can
 hijack your session and impersonate the originally authenticated user
 (even if that user originally authenticated on an encrypted channel).
 
 Do not, under any circumstances, design applications that depend on
 maintaining session state across an https -- http transition.
 
 Craig McClanahan
 
 
 --
 To unsubscribe, e-mail:   mailto:tomcat-user-unsubscribe;jakarta.apache.org
 For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
 
 
 

 --
 Your favorite stores, helpful shopping tools and great gift ideas.
 Experience the convenience of buying online with Shop@Netscape!
 http://shopnow.netscape.com/




--
To unsubscribe, e-mail:   mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org

Re: problem with session tracking and redirection http--- https

[Maninder S Batth]

if  session apis and request dispatchers are used for internal 
redirection, is there still any security hole??

Craig R. McClanahan wrote:

On Fri, 18 Oct 2002, Henrik Bentel wrote:

 

Date: Fri, 18 Oct 2002 23:07:17 +
From: Henrik Bentel [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: problem with session tracking and redirection http--- https



yeah, I always encode the redirection URL.
it's waird that it works if the session is created which under http, but not
under https.

bug maybe?

   


Nope ... avoidance of a huge security hole.

Once a session is accessed via https, it should never ever be allowed to
be accessed from http again.  The reason for this is that the session id
is transmitted in clear text, so anyone who can snoop the network can
hijack your session and impersonate the originally authenticated user
(even if that user originally authenticated on an encrypted channel).

Do not, under any circumstances, design applications that depend on
maintaining session state across an https -- http transition.

Craig McClanahan


--
To unsubscribe, e-mail:   mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org

 


--
Your favorite stores, helpful shopping tools and great gift ideas. 
Experience the convenience of buying online with Shop@Netscape! 
http://shopnow.netscape.com/

Re: problem with session tracking and redirection http--- https

[Craig R. McClanahan]

On Fri, 18 Oct 2002, Maninder S Batth wrote:

 Date: Fri, 18 Oct 2002 19:28:59 -0700
 From: Maninder S Batth [EMAIL PROTECTED]
 Reply-To: Tomcat Users List [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Re: problem with session tracking and redirection http--- https

 please correct me if i am wrong. Session id could be hijacked anytime if
 it is transmitted as clear text. so once user has loged in , and user
 gets new session id , this session id could be sniffed
 and the person can still be impersonated.??

Yes.

  how is this related to
 https--http transitiion?

If the session was originally established on the https connection, the
session id has never been transmitted in the clear, so it cannot be
hijacked except when the application accepts a non-https request for that
session (or the attacker can impersonate an existing SSL session, in which
case we've all got much bigger problems).

If the session was originally established under https, but the application
switches back to http, the session id is transmitted in the clear from
that point on, and is subject to hijacking.  This is the logical flaw we
discussed earlier this week with regards to a request to accept the login
screen on https (to avoid the password being transmitted in the clear) and
then switch back to http for the remainder of the session.  From the
security point of view, this is worse than useless (worse because it gives
you a false sense of confidence).

Craig




 Craig R. McClanahan wrote:

 On Fri, 18 Oct 2002, Henrik Bentel wrote:
 
 
 
 Date: Fri, 18 Oct 2002 23:07:17 +
 From: Henrik Bentel [EMAIL PROTECTED]
 Reply-To: Tomcat Users List [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Re: problem with session tracking and redirection http--- https
 
 
 
 yeah, I always encode the redirection URL.
 it's waird that it works if the session is created which under http, but not
 under https.
 
 bug maybe?
 
 
 
 
 Nope ... avoidance of a huge security hole.
 
 Once a session is accessed via https, it should never ever be allowed to
 be accessed from http again.  The reason for this is that the session id
 is transmitted in clear text, so anyone who can snoop the network can
 hijack your session and impersonate the originally authenticated user
 (even if that user originally authenticated on an encrypted channel).
 
 Do not, under any circumstances, design applications that depend on
 maintaining session state across an https -- http transition.
 
 Craig McClanahan
 
 
 --
 To unsubscribe, e-mail:   mailto:tomcat-user-unsubscribe;jakarta.apache.org
 For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
 
 
 

 --
 Your favorite stores, helpful shopping tools and great gift ideas.
 Experience the convenience of buying online with Shop@Netscape!
 http://shopnow.netscape.com/




--
To unsubscribe, e-mail:   mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org

Re: problem with session tracking and redirection http--- https

[Henrik Bentel]

One of my problems is that I can't find anything in the servlet or tomcat 
documentation that mentiones any of this behaviour. If there is any, please 
send me the link.

Also, since any time session tracking is used it can be picked up by 
someone, all use of https should stay strictly under https(ok, I'm over 
doing it). So basically if a webapp has any sensitive information, it should 
solely use https protocol for all transmissions, if using session tracking?

I don't see why the servlet container should force this behaviour. Shouldn't 
it be up to the developer to determine what is a security issue and not? 
Just like JSP doesn't neccesseraly force the separation of business logic 
and content, just allowing it, should the servlet container force a 
restrictive behaviour of session tracking?
A lot of web sites don't want the over head of sending everything over 
https. Only parts of it for secure user validation. But they still want 
session tracking.

Just as a simple example:
So let's say you use the existence of an http session as a validation for a 
logged in user, but you don't store any vital information.
And you only allow http sessions to be created under https protocol to 
secure the submition of password. Beyond that point, no sensitive data is 
shared, so users can be redirected back to http protocol.

With tomcat 4, the only way to use the same method would be to create a http 
seesion for every http request, then redirect to https, add some kind of 
validation flags in the session object, then redirect back. This to me is 
worse, as a DoS attack could force the servlet container to create a http 
session for every Request, really putting a strain on your container.

The example probably isn't a good example for how a typical website enforces 
secure validation, but I just want to raise the point that the hole is 
still there, since sessions created under http are available in all schemes. 
It could just as easily be misused by a developer.









From: Craig R. McClanahan [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Subject: Re: problem with session tracking and redirection http--- https
Date: Fri, 18 Oct 2002 21:48:36 -0700 (PDT)



On Fri, 18 Oct 2002, Maninder S Batth wrote:

 Date: Fri, 18 Oct 2002 19:28:59 -0700
 From: Maninder S Batth [EMAIL PROTECTED]
 Reply-To: Tomcat Users List [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Re: problem with session tracking and redirection http--- 
https

 please correct me if i am wrong. Session id could be hijacked anytime if
 it is transmitted as clear text. so once user has loged in , and user
 gets new session id , this session id could be sniffed
 and the person can still be impersonated.??

Yes.

  how is this related to
 https--http transitiion?

If the session was originally established on the https connection, the
session id has never been transmitted in the clear, so it cannot be
hijacked except when the application accepts a non-https request for that
session (or the attacker can impersonate an existing SSL session, in which
case we've all got much bigger problems).

If the session was originally established under https, but the application
switches back to http, the session id is transmitted in the clear from
that point on, and is subject to hijacking.  This is the logical flaw we
discussed earlier this week with regards to a request to accept the login
screen on https (to avoid the password being transmitted in the clear) and
then switch back to http for the remainder of the session.  From the
security point of view, this is worse than useless (worse because it gives
you a false sense of confidence).

Craig




 Craig R. McClanahan wrote:

 On Fri, 18 Oct 2002, Henrik Bentel wrote:
 
 
 
 Date: Fri, 18 Oct 2002 23:07:17 +
 From: Henrik Bentel [EMAIL PROTECTED]
 Reply-To: Tomcat Users List [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Re: problem with session tracking and redirection http--- 
https
 
 
 
 yeah, I always encode the redirection URL.
 it's waird that it works if the session is created which under http, 
but not
 under https.
 
 bug maybe?
 
 
 
 
 Nope ... avoidance of a huge security hole.
 
 Once a session is accessed via https, it should never ever be allowed 
to
 be accessed from http again.  The reason for this is that the session 
id
 is transmitted in clear text, so anyone who can snoop the network can
 hijack your session and impersonate the originally authenticated user
 (even if that user originally authenticated on an encrypted channel).
 
 Do not, under any circumstances, design applications that depend on
 maintaining session state across an https -- http transition.
 
 Craig McClanahan
 
 
 --
 To unsubscribe, e-mail:   
mailto:tomcat-user-unsubscribe;jakarta.apache.org
 For additional commands, e-mail: 
mailto:tomcat-user-help;jakarta.apache.org
 
 
 

 --
 Your favorite stores, helpful shopping tools and great gift ideas

Re: problem with session tracking and redirection http--- https

[Craig R. McClanahan]

On Thu, 17 Oct 2002, Henrik Bentel wrote:

 Date: Thu, 17 Oct 2002 04:45:21 +
 From: Henrik Bentel [EMAIL PROTECTED]
 Reply-To: Tomcat Users List [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Re: problem with session tracking and redirection http--- https


 ok, I see your point.
 My approach is that I only use https to scramble the login request itself,
 so that a login password cannot be read,or sniffed, in clear text(it
 probably still can, if someone really, really tries). Nothing critical is
 stored in the http session itself.

Doing this would be a total waste of time from a security perspective.
Nobody needs to see the password if they can see the session id and hijack
your session after you've logged on.  The only thing hiding the password
does is give you a false sense of security.

 A lot of websites do something similar, where only the password part is
 secure, and subsequent pages are insecure. and to change password, the old
 one has to be entered. I guess I'm a bit of a loss for a better way to do
 this?? Any well known approaches out there?


My advice would be to not use such applications yourself -- they can
clearly be hacked, so they are not trustworthy.


 -Henrik


Craig McClanahan


--
To unsubscribe, e-mail:   mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org

Re: problem with session tracking and redirection http--- https

[Maninder S Batth]

is the request method changing in redirection, for example post to get 
?? if it is, use HttpServletResponse.encodeURL()

Henrik Bentel wrote:


Another weird behaviour I just discovered is the following:

If a httpsession is created by a servlet processing a request sent 
under(scheme) http, then redirects to https, the session is available 
to the servlet processing in https. In other words, it stays put.

HOWEVER, if a httpsession is created by a servlet processing a request 
under https, and then redirects to http, the session is not available. 
But if one redirects back to https agin, the session is available.
Also, if you , after redirecting to http(where no session is to be 
found) create a new session, and then redirect  back to https, the 
original session is lost and the new session created in http scheme is 
the current one.

In tomcat3.3, session created in either schemes(http or https) stays 
put when redirecting.
I haven't found anything in the servlet specification that
mentiones anything about this behaviour.





From: Henrik Bentel [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: problem with session tracking and redirection http--- 
https
Date: Thu, 17 Oct 2002 04:45:21 +


ok, I see your point.
My approach is that I only use https to scramble the login request 
itself, so that a login password cannot be read,or sniffed, in clear 
text(it probably still can, if someone really, really tries). Nothing 
critical is stored in the http session itself.
A lot of websites do something similar, where only the password part 
is secure, and subsequent pages are insecure. and to change password, 
the old one has to be entered. I guess I'm a bit of a loss for a 
better way to do this?? Any well known approaches out there?


-Henrik

From: Jacob Kjome [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Subject: Re: problem with session tracking and redirection 
http---  https Date: Wed, 16 Oct 2002 23:33:41 -0500


This is the way Tomcat 4.x.x is made to work.  The reason for this 
is security.  I think it can be assumed that you were under https 
for a reason.  Maybe you entered your cedit card info and are 
storing that in the session until the final submit.  Now, if you 
stayed in the same session when moving to http from https, your 
session id is in plain text.  This can be hijacked by anyone 
sniffing network packets.  Once they have your session id, 
theoreticaly, they have full access to everything you entered in 
that session including your credit card info.  This is a *huge* 
security issue and Tomcat.  Even if Tomcat-3.3.x allows you to do 
this, you would be wise to dump the session on your own before 
moving to http for your users' security.

Obviously, this requires that you rethink some of your application 
flow, but Tomcat-4.x.x is doing the right thing here.

Jake

At 02:28 AM 10/17/2002 +, you wrote:

Help!

I recently tried to upgrade my version of Tomcat from 3.3 to 4.1(I 
also tried 4.0). My problem is that for some reason the httpsession 
is lost after redirection from https to http. I run apache in front 
of tomcat to handle static content plus certificate. My webapp 
depend on the ability to login a user of secure connection then 
redirect to an unsecure connection. I do the usual
res.sendRedirect(res.encodeRedirectURL.)). But after 
redirecting to http protocol (to the same webapp context) the http 
session is null.
My webapp workes fine in Tomcat 3.3. Nothing has changed except 
tomcat version and of course the tomcat conf. files. I've tried 
both the Coyote connector and the ajp13 one. mod_jk and 
mod_jk2(which I couldn't get working) on the apache side. I've 
tried Apache 1.3 and Apache 2. And I am going insane.
My server.xml file is close to the default one, I've only added my 
context(defining docbase and such). For 3.3 this worked like a charm.
Anyone??

-Henrik


_
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963


--
To unsubscribe, e-mail:   
mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: 
mailto:tomcat-user-help;jakarta.apache.org




_
Unlimited Internet access for only $21.95/month.  Try MSN! 
http://resourcecenter.msn.com/access/plans/2monthsfree.asp


--
To unsubscribe, e-mail:   
mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: 
mailto:tomcat-user-help;jakarta.apache.org



_
Get a speedy connection with MSN Broadband.  Join now! 
http://resourcecenter.msn.com/access/plans/freeactivation.asp


--
To unsubscribe, e-mail:   
mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: 
mailto:tomcat-user-help

Re: problem with session tracking and redirection http--- https

[Henrik Bentel]

Another weird behaviour I just discovered is the following:

If a httpsession is created by a servlet processing a request sent 
under(scheme) http, then redirects to https, the session is available to the 
servlet processing in https. In other words, it stays put.

HOWEVER, if a httpsession is created by a servlet processing a request under 
https, and then redirects to http, the session is not available. But if one 
redirects back to https agin, the session is available.
Also, if you , after redirecting to http(where no session is to be found) 
create a new session, and then redirect  back to https, the original session 
is lost and the new session created in http scheme is the current one.

In tomcat3.3, session created in either schemes(http or https) stays put 
when redirecting.
I haven't found anything in the servlet specification that
mentiones anything about this behaviour.





From: Henrik Bentel [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: problem with session tracking and redirection http--- https
Date: Thu, 17 Oct 2002 04:45:21 +


ok, I see your point.
My approach is that I only use https to scramble the login request itself, 
so that a login password cannot be read,or sniffed, in clear text(it 
probably still can, if someone really, really tries). Nothing critical is 
stored in the http session itself.
A lot of websites do something similar, where only the password part is 
secure, and subsequent pages are insecure. and to change password, the old 
one has to be entered. I guess I'm a bit of a loss for a better way to do 
this?? Any well known approaches out there?


-Henrik

From: Jacob Kjome [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Subject: Re: problem with session tracking and redirection http---  
https Date: Wed, 16 Oct 2002 23:33:41 -0500


This is the way Tomcat 4.x.x is made to work.  The reason for this is 
security.  I think it can be assumed that you were under https for a 
reason.  Maybe you entered your cedit card info and are storing that in 
the session until the final submit.  Now, if you stayed in the same 
session when moving to http from https, your session id is in plain text.  
This can be hijacked by anyone sniffing network packets.  Once they have 
your session id, theoreticaly, they have full access to everything you 
entered in that session including your credit card info.  This is a *huge* 
security issue and Tomcat.  Even if Tomcat-3.3.x allows you to do this, 
you would be wise to dump the session on your own before moving to http 
for your users' security.

Obviously, this requires that you rethink some of your application flow, 
but Tomcat-4.x.x is doing the right thing here.

Jake

At 02:28 AM 10/17/2002 +, you wrote:
Help!

I recently tried to upgrade my version of Tomcat from 3.3 to 4.1(I also 
tried 4.0). My problem is that for some reason the httpsession is lost 
after redirection from https to http. I run apache in front of tomcat to 
handle static content plus certificate. My webapp depend on the ability 
to login a user of secure connection then redirect to an unsecure 
connection. I do the usual
res.sendRedirect(res.encodeRedirectURL.)). But after redirecting to 
http protocol (to the same webapp context) the http session is null.
My webapp workes fine in Tomcat 3.3. Nothing has changed except tomcat 
version and of course the tomcat conf. files. I've tried both the Coyote 
connector and the ajp13 one. mod_jk and mod_jk2(which I couldn't get 
working) on the apache side. I've tried Apache 1.3 and Apache 2. And I am 
going insane.
My server.xml file is close to the default one, I've only added my 
context(defining docbase and such). For 3.3 this worked like a charm.
Anyone??

-Henrik


_
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963


--
To unsubscribe, e-mail:   
mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: 
mailto:tomcat-user-help;jakarta.apache.org


_
Unlimited Internet access for only $21.95/month.  Try MSN! 
http://resourcecenter.msn.com/access/plans/2monthsfree.asp


--
To unsubscribe, e-mail:   
mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: 
mailto:tomcat-user-help;jakarta.apache.org


_
Get a speedy connection with MSN Broadband.  Join now! 
http://resourcecenter.msn.com/access/plans/freeactivation.asp


--
To unsubscribe, e-mail:   mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org

Re: problem with session tracking and redirection http--- https

[Henrik Bentel]

yeah, I always encode the redirection URL.
it's waird that it works if the session is created which under http, but not 
under https.

bug maybe?


From: Maninder S Batth [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: problem with session tracking and redirection http--- https
Date: Fri, 18 Oct 2002 14:13:40 -0700

is the request method changing in redirection, for example post to get ?? 
if it is, use HttpServletResponse.encodeURL()

Henrik Bentel wrote:


Another weird behaviour I just discovered is the following:

If a httpsession is created by a servlet processing a request sent 
under(scheme) http, then redirects to https, the session is available to 
the servlet processing in https. In other words, it stays put.

HOWEVER, if a httpsession is created by a servlet processing a request 
under https, and then redirects to http, the session is not available. But 
if one redirects back to https agin, the session is available.
Also, if you , after redirecting to http(where no session is to be found) 
create a new session, and then redirect  back to https, the original 
session is lost and the new session created in http scheme is the current 
one.

In tomcat3.3, session created in either schemes(http or https) stays put 
when redirecting.
I haven't found anything in the servlet specification that
mentiones anything about this behaviour.





From: Henrik Bentel [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: problem with session tracking and redirection http--- 
https
Date: Thu, 17 Oct 2002 04:45:21 +


ok, I see your point.
My approach is that I only use https to scramble the login request 
itself, so that a login password cannot be read,or sniffed, in clear 
text(it probably still can, if someone really, really tries). Nothing 
critical is stored in the http session itself.
A lot of websites do something similar, where only the password part is 
secure, and subsequent pages are insecure. and to change password, the 
old one has to be entered. I guess I'm a bit of a loss for a better way 
to do this?? Any well known approaches out there?


-Henrik

From: Jacob Kjome [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Subject: Re: problem with session tracking and redirection http---  
https Date: Wed, 16 Oct 2002 23:33:41 -0500


This is the way Tomcat 4.x.x is made to work.  The reason for this is 
security.  I think it can be assumed that you were under https for a 
reason.  Maybe you entered your cedit card info and are storing that in 
the session until the final submit.  Now, if you stayed in the same 
session when moving to http from https, your session id is in plain 
text.  This can be hijacked by anyone sniffing network packets.  Once 
they have your session id, theoreticaly, they have full access to 
everything you entered in that session including your credit card info.  
This is a *huge* security issue and Tomcat.  Even if Tomcat-3.3.x allows 
you to do this, you would be wise to dump the session on your own before 
moving to http for your users' security.

Obviously, this requires that you rethink some of your application flow, 
but Tomcat-4.x.x is doing the right thing here.

Jake

At 02:28 AM 10/17/2002 +, you wrote:

Help!

I recently tried to upgrade my version of Tomcat from 3.3 to 4.1(I also 
tried 4.0). My problem is that for some reason the httpsession is lost 
after redirection from https to http. I run apache in front of tomcat 
to handle static content plus certificate. My webapp depend on the 
ability to login a user of secure connection then redirect to an 
unsecure connection. I do the usual
res.sendRedirect(res.encodeRedirectURL.)). But after redirecting to 
http protocol (to the same webapp context) the http session is null.
My webapp workes fine in Tomcat 3.3. Nothing has changed except tomcat 
version and of course the tomcat conf. files. I've tried both the 
Coyote connector and the ajp13 one. mod_jk and mod_jk2(which I couldn't 
get working) on the apache side. I've tried Apache 1.3 and Apache 2. 
And I am going insane.
My server.xml file is close to the default one, I've only added my 
context(defining docbase and such). For 3.3 this worked like a charm.
Anyone??

-Henrik


_
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963


--
To unsubscribe, e-mail:   
mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: 
mailto:tomcat-user-help;jakarta.apache.org




_
Unlimited Internet access for only $21.95/month.  Try MSN! 
http://resourcecenter.msn.com/access/plans/2monthsfree.asp


--
To unsubscribe, e-mail:   
mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail

Re: problem with session tracking and redirection http--- https

[Maninder S Batth]

This is what i did:
1. use makes https request to tomcat for a jsp page , the jsp page 
creates a session and adds a variable into session.
This jsp page has hyerlink to another ShowVar.jsp but the hyperlink uses 
http protocol..
2. i click on the link and ShowVar.jsp displays me the session variable 
which was created by https jsp.
The first file is called PutVar.jsp . It works fine. I am including both 
the files.


Henrik Bentel wrote:



yeah, I always encode the redirection URL.
it's waird that it works if the session is created which under http, 
but not under https.

bug maybe?


From: Maninder S Batth [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: problem with session tracking and redirection http--- 
https
Date: Fri, 18 Oct 2002 14:13:40 -0700

is the request method changing in redirection, for example post to 
get ?? if it is, use HttpServletResponse.encodeURL()

Henrik Bentel wrote:


Another weird behaviour I just discovered is the following:

If a httpsession is created by a servlet processing a request sent 
under(scheme) http, then redirects to https, the session is 
available to the servlet processing in https. In other words, it 
stays put.

HOWEVER, if a httpsession is created by a servlet processing a 
request under https, and then redirects to http, the session is not 
available. But if one redirects back to https agin, the session is 
available.
Also, if you , after redirecting to http(where no session is to be 
found) create a new session, and then redirect  back to https, the 
original session is lost and the new session created in http scheme 
is the current one.

In tomcat3.3, session created in either schemes(http or https) 
stays put when redirecting.
I haven't found anything in the servlet specification that
mentiones anything about this behaviour.





From: Henrik Bentel [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: problem with session tracking and redirection 
http--- https
Date: Thu, 17 Oct 2002 04:45:21 +


ok, I see your point.
My approach is that I only use https to scramble the login request 
itself, so that a login password cannot be read,or sniffed, in 
clear text(it probably still can, if someone really, really tries). 
Nothing critical is stored in the http session itself.
A lot of websites do something similar, where only the password 
part is secure, and subsequent pages are insecure. and to change 
password, the old one has to be entered. I guess I'm a bit of a 
loss for a better way to do this?? Any well known approaches out 
there?


-Henrik

From: Jacob Kjome [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Subject: Re: problem with session tracking and redirection 
http---  https Date: Wed, 16 Oct 2002 23:33:41 -0500


This is the way Tomcat 4.x.x is made to work.  The reason for this 
is security.  I think it can be assumed that you were under https 
for a reason.  Maybe you entered your cedit card info and are 
storing that in the session until the final submit.  Now, if you 
stayed in the same session when moving to http from https, your 
session id is in plain text.  This can be hijacked by anyone 
sniffing network packets.  Once they have your session id, 
theoreticaly, they have full access to everything you entered in 
that session including your credit card info.  This is a *huge* 
security issue and Tomcat.  Even if Tomcat-3.3.x allows you to do 
this, you would be wise to dump the session on your own before 
moving to http for your users' security.

Obviously, this requires that you rethink some of your application 
flow, but Tomcat-4.x.x is doing the right thing here.

Jake

At 02:28 AM 10/17/2002 +, you wrote:

Help!

I recently tried to upgrade my version of Tomcat from 3.3 to 
4.1(I also tried 4.0). My problem is that for some reason the 
httpsession is lost after redirection from https to http. I run 
apache in front of tomcat to handle static content plus 
certificate. My webapp depend on the ability to login a user of 
secure connection then redirect to an unsecure connection. I do 
the usual
res.sendRedirect(res.encodeRedirectURL.)). But after 
redirecting to http protocol (to the same webapp context) the 
http session is null.
My webapp workes fine in Tomcat 3.3. Nothing has changed except 
tomcat version and of course the tomcat conf. files. I've tried 
both the Coyote connector and the ajp13 one. mod_jk and 
mod_jk2(which I couldn't get working) on the apache side. I've 
tried Apache 1.3 and Apache 2. And I am going insane.
My server.xml file is close to the default one, I've only added 
my context(defining docbase and such). For 3.3 this worked like a 
charm.
Anyone??

-Henrik


_
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

Re: problem with session tracking and redirection http--- https

[Maninder S Batth]

btw does RequestDispatcher serves your purpose ?

Henrik Bentel wrote:




yeah, I always encode the redirection URL.
it's waird that it works if the session is created which under http, 
but not under https.

bug maybe?


From: Maninder S Batth [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: problem with session tracking and redirection http--- 
https
Date: Fri, 18 Oct 2002 14:13:40 -0700

is the request method changing in redirection, for example post to 
get ?? if it is, use HttpServletResponse.encodeURL()

Henrik Bentel wrote:


Another weird behaviour I just discovered is the following:

If a httpsession is created by a servlet processing a request sent 
under(scheme) http, then redirects to https, the session is 
available to the servlet processing in https. In other words, it 
stays put.

HOWEVER, if a httpsession is created by a servlet processing a 
request under https, and then redirects to http, the session is not 
available. But if one redirects back to https agin, the session is 
available.
Also, if you , after redirecting to http(where no session is to be 
found) create a new session, and then redirect  back to https, the 
original session is lost and the new session created in http scheme 
is the current one.

In tomcat3.3, session created in either schemes(http or https) 
stays put when redirecting.
I haven't found anything in the servlet specification that
mentiones anything about this behaviour.





From: Henrik Bentel [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: problem with session tracking and redirection 
http--- https
Date: Thu, 17 Oct 2002 04:45:21 +


ok, I see your point.
My approach is that I only use https to scramble the login request 
itself, so that a login password cannot be read,or sniffed, in 
clear text(it probably still can, if someone really, really tries). 
Nothing critical is stored in the http session itself.
A lot of websites do something similar, where only the password 
part is secure, and subsequent pages are insecure. and to change 
password, the old one has to be entered. I guess I'm a bit of a 
loss for a better way to do this?? Any well known approaches out 
there?


-Henrik

From: Jacob Kjome [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Subject: Re: problem with session tracking and redirection 
http---  https Date: Wed, 16 Oct 2002 23:33:41 -0500


This is the way Tomcat 4.x.x is made to work.  The reason for this 
is security.  I think it can be assumed that you were under https 
for a reason.  Maybe you entered your cedit card info and are 
storing that in the session until the final submit.  Now, if you 
stayed in the same session when moving to http from https, your 
session id is in plain text.  This can be hijacked by anyone 
sniffing network packets.  Once they have your session id, 
theoreticaly, they have full access to everything you entered in 
that session including your credit card info.  This is a *huge* 
security issue and Tomcat.  Even if Tomcat-3.3.x allows you to do 
this, you would be wise to dump the session on your own before 
moving to http for your users' security.

Obviously, this requires that you rethink some of your application 
flow, but Tomcat-4.x.x is doing the right thing here.

Jake

At 02:28 AM 10/17/2002 +, you wrote:

Help!

I recently tried to upgrade my version of Tomcat from 3.3 to 
4.1(I also tried 4.0). My problem is that for some reason the 
httpsession is lost after redirection from https to http. I run 
apache in front of tomcat to handle static content plus 
certificate. My webapp depend on the ability to login a user of 
secure connection then redirect to an unsecure connection. I do 
the usual
res.sendRedirect(res.encodeRedirectURL.)). But after 
redirecting to http protocol (to the same webapp context) the 
http session is null.
My webapp workes fine in Tomcat 3.3. Nothing has changed except 
tomcat version and of course the tomcat conf. files. I've tried 
both the Coyote connector and the ajp13 one. mod_jk and 
mod_jk2(which I couldn't get working) on the apache side. I've 
tried Apache 1.3 and Apache 2. And I am going insane.
My server.xml file is close to the default one, I've only added 
my context(defining docbase and such). For 3.3 this worked like a 
charm.
Anyone??

-Henrik


_
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963


--
To unsubscribe, e-mail:   
mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: 
mailto:tomcat-user-help;jakarta.apache.org





_
Unlimited Internet access for only $21.95/month.  Try MSN! 
http://resourcecenter.msn.com/access/plans/2monthsfree.asp


--
To unsubscribe, e-mail

Re: problem with session tracking and redirection http--- https

[Craig R. McClanahan]

On Fri, 18 Oct 2002, Henrik Bentel wrote:

 Date: Fri, 18 Oct 2002 23:07:17 +
 From: Henrik Bentel [EMAIL PROTECTED]
 Reply-To: Tomcat Users List [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Re: problem with session tracking and redirection http--- https



 yeah, I always encode the redirection URL.
 it's waird that it works if the session is created which under http, but not
 under https.

 bug maybe?


Nope ... avoidance of a huge security hole.

Once a session is accessed via https, it should never ever be allowed to
be accessed from http again.  The reason for this is that the session id
is transmitted in clear text, so anyone who can snoop the network can
hijack your session and impersonate the originally authenticated user
(even if that user originally authenticated on an encrypted channel).

Do not, under any circumstances, design applications that depend on
maintaining session state across an https -- http transition.

Craig McClanahan


--
To unsubscribe, e-mail:   mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org

Re: problem with session tracking and redirection http--- https

[Maninder S Batth]

please correct me if i am wrong. Session id could be hijacked anytime if 
it is transmitted as clear text. so once user has loged in , and user 
gets new session id , this session id could be sniffed
and the person can still be impersonated.??  how is this related to 
https--http transitiion?

Craig R. McClanahan wrote:

On Fri, 18 Oct 2002, Henrik Bentel wrote:

 

Date: Fri, 18 Oct 2002 23:07:17 +
From: Henrik Bentel [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: problem with session tracking and redirection http--- https



yeah, I always encode the redirection URL.
it's waird that it works if the session is created which under http, but not
under https.

bug maybe?

   


Nope ... avoidance of a huge security hole.

Once a session is accessed via https, it should never ever be allowed to
be accessed from http again.  The reason for this is that the session id
is transmitted in clear text, so anyone who can snoop the network can
hijack your session and impersonate the originally authenticated user
(even if that user originally authenticated on an encrypted channel).

Do not, under any circumstances, design applications that depend on
maintaining session state across an https -- http transition.

Craig McClanahan


--
To unsubscribe, e-mail:   mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org

 


--
Your favorite stores, helpful shopping tools and great gift ideas. 
Experience the convenience of buying online with Shop@Netscape! 
http://shopnow.netscape.com/

AW: problem with session tracking and redirection http--- https

[Ralph Einfeldt]

If the login is so critical that you want/have to 
encrypt it, it doesn't make much sense to me to 
open that session to anyone who can listen to 
your traffic.

If there can't be done any harm after the login, why 
even bother to encrypt the user/password ?

One option for you to work around this, would be 
(roughly) something like this:

- Create a hashtable that is global to the webapp.
- Create a hashtable for each session
- Store the session hashtable in the application 
  Hashtable and use the session id as key
- if (session.isNew()  (RequestedSessionId != null))
  get the session hashtable by using the RequestedSessionId
  and store it with the new SessionId as key.
- otherwise get the session hashtable by using the 
  current session id.
- Store your session variables in the session hashtable
- make shure to remove every thing from the application
  hashtable whenever a session gets destroyed.

 -Ursprüngliche Nachricht-
 Von: Henrik Bentel [mailto:[EMAIL PROTECTED]]
 Gesendet: Donnerstag, 17. Oktober 2002 06:45
 An: [EMAIL PROTECTED]
 Betreff: Re: problem with session tracking and redirection http---
 https
 
 My approach is that I only use https to scramble the login 
 request itself, so that a login password cannot be read, or sniffed, 
 in clear text. 
snip/
 Nothing critical is stored in the http session itself.
snip/

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

problem with session tracking and redirection http--- https

[Henrik Bentel]

Help!

I recently tried to upgrade my version of Tomcat from 3.3 to 4.1(I also 
tried 4.0). My problem is that for some reason the httpsession is lost after 
redirection from https to http. I run apache in front of tomcat to handle 
static content plus certificate. My webapp depend on the ability to login a 
user of secure connection then redirect to an unsecure connection. I do the 
usual
res.sendRedirect(res.encodeRedirectURL.)). But after redirecting to http 
protocol (to the same webapp context) the http session is null.
My webapp workes fine in Tomcat 3.3. Nothing has changed except tomcat 
version and of course the tomcat conf. files. I've tried both the Coyote 
connector and the ajp13 one. mod_jk and mod_jk2(which I couldn't get 
working) on the apache side. I've tried Apache 1.3 and Apache 2. And I am 
going insane.
My server.xml file is close to the default one, I've only added my 
context(defining docbase and such). For 3.3 this worked like a charm.
Anyone??

-Henrik


_
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: problem with session tracking and redirection http--- https

[Jacob Kjome]

This is the way Tomcat 4.x.x is made to work.  The reason for this is 
security.  I think it can be assumed that you were under https for a 
reason.  Maybe you entered your cedit card info and are storing that in the 
session until the final submit.  Now, if you stayed in the same session 
when moving to http from https, your session id is in plain text.  This can 
be hijacked by anyone sniffing network packets.  Once they have your 
session id, theoreticaly, they have full access to everything you entered 
in that session including your credit card info.  This is a *huge* security 
issue and Tomcat.  Even if Tomcat-3.3.x allows you to do this, you would be 
wise to dump the session on your own before moving to http for your users' 
security.

Obviously, this requires that you rethink some of your application flow, 
but Tomcat-4.x.x is doing the right thing here.

Jake

At 02:28 AM 10/17/2002 +, you wrote:
Help!

I recently tried to upgrade my version of Tomcat from 3.3 to 4.1(I also 
tried 4.0). My problem is that for some reason the httpsession is lost 
after redirection from https to http. I run apache in front of tomcat to 
handle static content plus certificate. My webapp depend on the ability to 
login a user of secure connection then redirect to an unsecure connection. 
I do the usual
res.sendRedirect(res.encodeRedirectURL.)). But after redirecting to 
http protocol (to the same webapp context) the http session is null.
My webapp workes fine in Tomcat 3.3. Nothing has changed except tomcat 
version and of course the tomcat conf. files. I've tried both the Coyote 
connector and the ajp13 one. mod_jk and mod_jk2(which I couldn't get 
working) on the apache side. I've tried Apache 1.3 and Apache 2. And I am 
going insane.
My server.xml file is close to the default one, I've only added my 
context(defining docbase and such). For 3.3 this worked like a charm.
Anyone??

-Henrik


_
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: problem with session tracking and redirection http--- https

[Henrik Bentel]

ok, I see your point.
My approach is that I only use https to scramble the login request itself, 
so that a login password cannot be read,or sniffed, in clear text(it 
probably still can, if someone really, really tries). Nothing critical is 
stored in the http session itself.
A lot of websites do something similar, where only the password part is 
secure, and subsequent pages are insecure. and to change password, the old 
one has to be entered. I guess I'm a bit of a loss for a better way to do 
this?? Any well known approaches out there?


-Henrik

From: Jacob Kjome [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Subject: Re: problem with session tracking and redirection http---  https 
Date: Wed, 16 Oct 2002 23:33:41 -0500


This is the way Tomcat 4.x.x is made to work.  The reason for this is 
security.  I think it can be assumed that you were under https for a 
reason.  Maybe you entered your cedit card info and are storing that in the 
session until the final submit.  Now, if you stayed in the same session 
when moving to http from https, your session id is in plain text.  This can 
be hijacked by anyone sniffing network packets.  Once they have your 
session id, theoreticaly, they have full access to everything you entered 
in that session including your credit card info.  This is a *huge* security 
issue and Tomcat.  Even if Tomcat-3.3.x allows you to do this, you would be 
wise to dump the session on your own before moving to http for your users' 
security.

Obviously, this requires that you rethink some of your application flow, 
but Tomcat-4.x.x is doing the right thing here.

Jake

At 02:28 AM 10/17/2002 +, you wrote:
Help!

I recently tried to upgrade my version of Tomcat from 3.3 to 4.1(I also 
tried 4.0). My problem is that for some reason the httpsession is lost 
after redirection from https to http. I run apache in front of tomcat to 
handle static content plus certificate. My webapp depend on the ability to 
login a user of secure connection then redirect to an unsecure connection. 
I do the usual
res.sendRedirect(res.encodeRedirectURL.)). But after redirecting to 
http protocol (to the same webapp context) the http session is null.
My webapp workes fine in Tomcat 3.3. Nothing has changed except tomcat 
version and of course the tomcat conf. files. I've tried both the Coyote 
connector and the ajp13 one. mod_jk and mod_jk2(which I couldn't get 
working) on the apache side. I've tried Apache 1.3 and Apache 2. And I am 
going insane.
My server.xml file is close to the default one, I've only added my 
context(defining docbase and such). For 3.3 this worked like a charm.
Anyone??

-Henrik


_
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963


--
To unsubscribe, e-mail:   
mailto:[EMAIL PROTECTED]
For additional commands, e-mail: 
mailto:[EMAIL PROTECTED]


_
Unlimited Internet access for only $21.95/month.  Try MSN! 
http://resourcecenter.msn.com/access/plans/2monthsfree.asp


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Adicional configuration when using IIS redirection.

[Rafael Gava de Oliveira]

Hello, 

I´ve configured TomCat 4.0.4 to work with IIS. Everything is working fine but 
I didn´t setup a Connector in Server.XML. Is it ok? Do I have to setup a connector? Or 
if would like to setup a number of connections (threads), Do I have to setup a 
connector?

Tanks.



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Unique session ID upon redirection

[A.P Kwee]

Hi,

I hope that this is the right channel to post this question.

I am trying to force all requests for *.html pages to a jsp file which 
will perform some checks on whether the users has logged on before 
displaying the html file.

I have successfully redirected all request from my apache webserver to 
my tomcat using mod_rewrite but I am facing this problem that every 
request that gets rewritten to the jsp file is a unique session id. I've 
verified this by doing a println for the sessionid.

I would appreciate greatly if anyone can share some light on my problem.

Thks and Best Regards,
Ann Peng




--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

determining URL selected prior to redirection for j_security_check?

[Stadter, Jim]

Hi,

  My index.html page contains three links, two of
which require authorization prior to access.  I'm
using form based authentication, and would like to
customize the login.jsp page (which contains the j_security_check
form) to provide an indication of the original link that was selected from 
index.html.  Is there a way to determine the original link 
that was selected prior to the container redirecting to
login.jsp?

  I'm using tomcat 4.0.3.

  Thanks for any insight.

Jim

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

RE: determining URL selected prior to redirection for j_security_check?

[Durham David Cntr 805CSS/SCBE]

Yeah, there's a lot of ways to do that.

do something like:

if (!loggedIn) {
response.sendRedirect(login.jsp?redirect= + request.getRequestURI());
return;
}


then on the login form:
input type=hidden name=redirect value=%= 
request.getParameter(redirect)%
or
form action=login_act.jsp?redirect=%= request.getParameter(redirect) %




-Original Message-
From: Stadter, Jim [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 24, 2002 4:55 PM
To: [EMAIL PROTECTED]
Subject: determining URL selected prior to redirection for
j_security_check?


Hi,

  My index.html page contains three links, two of
which require authorization prior to access.  I'm
using form based authentication, and would like to
customize the login.jsp page (which contains the j_security_check
form) to provide an indication of the original link that was selected from 
index.html.  Is there a way to determine the original link 
that was selected prior to the container redirecting to
login.jsp?

  I'm using tomcat 4.0.3.

  Thanks for any insight.

Jim

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]