date:20200218

Chris,

strange, as I thought I specified secretRequired="false" and so don't need any 
secret, but anyway:
that's it -- Thank you!

Now without secret="" and without mod_jk everything works fine.

Regards,
Friderike Hofmeister
 


> Christopher Schultz  hat am 18. Februar 2020 
> 17:07 geschrieben:
> 
>  
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Friderike,
> 
> On 2/18/20 07:36, Friderike Hofmeister wrote:
> > for our application we have to use the AJP protocol and so I
> > understand with Tomcat 8.5.51 we have to configure the AJP
> > connector as follows:
> >
> >  > redirectPort="8443" secretRequired="false" secret="" />
> 
> You don't want secret="", which is different than leaving it unset.
> Setting it to "" means it's set to an empty string.
> 
> I think you just want to remove the "secret" attribute altogether.
> 
> > With this browser error message changed to "403 -- Der Server hat
> > die Anfrage verstanden, verbietet aber eine Autoriesierung."
> Are there any other specific error messages in the logs?
> 
> - -chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Embedding with Tomcat 9

2020-02-18 Thread Thad Humphries

On Tue, Feb 18, 2020 at 6:29 PM Mark Thomas  wrote:

> On 18/02/2020 23:13, Thad Humphries wrote:
> > On Tue, Feb 18, 2020 at 5:41 PM Mark Thomas  wrote:
> >> On 18/02/2020 22:32, calder wrote:
> >>> On Tue, Feb 18, 2020, 14:12 Thad Humphries 
>
> 
>
>  However although this runs it returns a 404 on /employee. Why?
> >>
> >> There aren't (doesn't appear to be)  any Servlets mapped.
> >>
> >> Are there any web applications in the appBase?
> >>
> >
> > There is a servlet
> > in src/main/java/com/example/employees, EmployeeServlet.java, with the
> > annotation
> >
> >   @WebServlet(
> > name = "EmployeeServlet",
> > urlPatterns = {"/employee"}
> >   )
>
> OK. That will be relying on the StandardJarScanner finding that class -
> which it should.
>
> > In src/main/webapp is the file index.jsp which redirects to /employee:
>
> OK. Maven is copying that to META-INF/resources and hoping that Tomcat
> will treat the entire JAR as a resource JAR. That should work.
>
> > <%@ page info="sample index page" %>
> > 
> > 
> > Hello World!
> > 
> > 
> > 
> >
> > With Tomcat 7.0.57, I can run `java -jar
> > employees-app-1.0-SNAPSHOT-jar-with-dependencies.jar` in target, and load
> > the page at http://localhost:/.  With Tomcat 9.0.31, I get a 404
>
> Not sure which part is failing at this point. Using a purely static JSP
> without the forward and accessing /employee directly should tell you which.


If I comment out the jsp:forward, http://localhost:/ loads. However
http://localhost:/employee
still returns a 404.

I'd then recommend debugging your way though the Tomcat start process to
>
see where whichever element is failing is going wrong.
>

I'll see if I can figure out how to do that. Eclipse and I are not on the
best of terms. Frankly, loading JSPs is not something I need to do for how
I envision using embedded Tomcat. But I figure I need to know what's
happening because if I don't, I'm sure to run into problems down the road
when I'm dealing with something more complex.

-- 
"Hell hath no limits, nor is circumscrib'd In one self-place; but where we
are is hell, And where hell is, there must we ever be" --Christopher
Marlowe, *Doctor Faustus* (v. 111-13)

Re: Embedding with Tomcat 9

On 18/02/2020 23:13, Thad Humphries wrote:
> On Tue, Feb 18, 2020 at 5:41 PM Mark Thomas  wrote:
>> On 18/02/2020 22:32, calder wrote:
>>> On Tue, Feb 18, 2020, 14:12 Thad Humphries 

 However although this runs it returns a 404 on /employee. Why?
>>
>> There aren't (doesn't appear to be)  any Servlets mapped.
>>
>> Are there any web applications in the appBase?
>>
> 
> There is a servlet
> in src/main/java/com/example/employees, EmployeeServlet.java, with the
> annotation
> 
>   @WebServlet(
> name = "EmployeeServlet",
> urlPatterns = {"/employee"}
>   )

OK. That will be relying on the StandardJarScanner finding that class -
which it should.

> In src/main/webapp is the file index.jsp which redirects to /employee:

OK. Maven is copying that to META-INF/resources and hoping that Tomcat
will treat the entire JAR as a resource JAR. That should work.

> <%@ page info="sample index page" %>
> 
> 
> Hello World!
> 
> 
> 
> 
> With Tomcat 7.0.57, I can run `java -jar
> employees-app-1.0-SNAPSHOT-jar-with-dependencies.jar` in target, and load
> the page at http://localhost:/.  With Tomcat 9.0.31, I get a 404

Not sure which part is failing at this point. Using a purely static JSP
without the forward and accessing /employee directly should tell you which.

I'd then recommend debugging your way though the Tomcat start process to
see where whichever element is failing is going wrong.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Embedding with Tomcat 9

2020-02-18 Thread Thad Humphries

On Tue, Feb 18, 2020 at 5:41 PM Mark Thomas  wrote:

> On 18/02/2020 22:32, calder wrote:
> > On Tue, Feb 18, 2020, 14:12 Thad Humphries 
> wrote:
> >
> >> I am trying to understand how to build and run an app from local with
> >> Tomcat 9 embedded using Java 8. I've started with this example written
> for
> >> Tomcat 7:
> >>
> >>
> https://www.oracle.com/webfolder/technetwork/tutorials/obe/java/basic_app_embedded_tomcat/basic_app-tomcat-embedded.html#overview
> >>
> >> I am able to get it to run with Tomcat 9 after a few changes to the
> pom.xml
> >> and one addition to the main() method:
> >>
> >> public static void main(String[] args) throws Exception {
> >>
> >
> >
> >   String contextPath = "" ;
> >>
> >
> > May not be the issue, cause there's other code to consider, but should
> the
> > above line be
> >
> > String contextPath = "/" ;
>
> No. "" is the correct path for the ROOT context.
>
>
> >>   String appBase = ".";
> >>   Tomcat tomcat = new Tomcat();
> >>   tomcat.setPort(Integer.valueOf(PORT.orElse("") ));
> >>   // next line added for Tomcat 9
> >>   tomcat.setConnector(tomcat.getConnector());
> >>
> >>   tomcat.setHostname(HOSTNAME.orElse("localhost"));
> >>   tomcat.getHost().setAppBase(appBase);
> >>   tomcat.addWebapp(contextPath, appBase);
> >>   tomcat.start();
> >>   tomcat.getServer().await();
> >> }
> >>
> >> However although this runs it returns a 404 on /employee. Why?
>
> There aren't (doesn't appear to be)  any Servlets mapped.
>
> Are there any web applications in the appBase?
>

There is a servlet
in src/main/java/com/example/employees, EmployeeServlet.java, with the
annotation

  @WebServlet(
name = "EmployeeServlet",
urlPatterns = {"/employee"}
  )

In src/main/webapp is the file index.jsp which redirects to /employee:

<%@ page info="sample index page" %>


Hello World!




With Tomcat 7.0.57, I can run `java -jar
employees-app-1.0-SNAPSHOT-jar-with-dependencies.jar` in target, and load
the page at http://localhost:/.  With Tomcat 9.0.31, I get a 404

-- 
"Hell hath no limits, nor is circumscrib'd In one self-place; but where we
are is hell, And where hell is, there must we ever be" --Christopher
Marlowe, *Doctor Faustus* (v. 111-13)

Re: Expect: 100-continue with filters vs valves

On 18/02/2020 19:47, Michael Osipov wrote:
> Am 2020-02-18 um 20:28 schrieb Mark Thomas:



>> Got it - I think. Let me re-phrase to see if I understand correctly.
>>
>> You have a code fragment that issues a redirect.
>>
>> The app submits a request with an header "Expect: 100-continue"
>>
>> With the valve the sequence is:
>> - request
>> - redirect
>> - request
>> - 100 Continue
>> - response
>>
>> With the filter the sequence is:
>> - request
>> - 100 Continue
>> - redirect (and body will be swallowed)
>> - request
>> - 100 Continue
>> - response
> 
> Exactly!
> 
>> The questions is "Why the difference?" as the Filter is less efficient.
>> It ends up sending the body twice.
>>
>> The answer is that Tomcat has to provide the "100 Continue" response
>> since there isn't a Servlet API for the app to do so. It does this as
>> the final act in the Context's pipeline (valve collection). That means
>> it happens after any Engine/Host/Context Valves you have configured but
>> before any Filters.
>>
>> This enhancement request would help:
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=57661
>>
>> but it would need to be made optional as it will add a delay to the
>> request processing in some circumstances.
> 
> Now this makes sense. This basically means that something like this [1]
> cannot efficiently implemented w/o using a valve?

Yes.

> If you say this is also a limitation in the Servlet API, it is worth to
> raise that as a clarification point?

Sure. It won't happen until at least Servlet 5.1 though. 5.0 is limited
to the javax -> jakarta rename and posisble some minor clean-up.

> It might be worth adding to docs/config/valve.html when a valve is more
> approriate than a filter. This is clearly a pitfall for such a case.

Indeed.

Mark

> 
> Thanks for the clarification.
> 
> [1]
> https://github.com/csviri/bodylimiter/blob/master/src/main/java/com/csviri/security/filter/bodylength/RequestMessageBodyLengthLimitFilter.java
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Embedding with Tomcat 9

On 18/02/2020 22:32, calder wrote:
> On Tue, Feb 18, 2020, 14:12 Thad Humphries  wrote:
> 
>> I am trying to understand how to build and run an app from local with
>> Tomcat 9 embedded using Java 8. I've started with this example written for
>> Tomcat 7:
>>
>> https://www.oracle.com/webfolder/technetwork/tutorials/obe/java/basic_app_embedded_tomcat/basic_app-tomcat-embedded.html#overview
>>
>> I am able to get it to run with Tomcat 9 after a few changes to the pom.xml
>> and one addition to the main() method:
>>
>> public static void main(String[] args) throws Exception {
>>
> 
> 
>   String contextPath = "" ;
>>
> 
> May not be the issue, cause there's other code to consider, but should the
> above line be
> 
> String contextPath = "/" ;

No. "" is the correct path for the ROOT context.


>>   String appBase = ".";
>>   Tomcat tomcat = new Tomcat();
>>   tomcat.setPort(Integer.valueOf(PORT.orElse("") ));
>>   // next line added for Tomcat 9
>>   tomcat.setConnector(tomcat.getConnector());
>>
>>   tomcat.setHostname(HOSTNAME.orElse("localhost"));
>>   tomcat.getHost().setAppBase(appBase);
>>   tomcat.addWebapp(contextPath, appBase);
>>   tomcat.start();
>>   tomcat.getServer().await();
>> }
>>
>> However although this runs it returns a 404 on /employee. Why?

There aren't (doesn't appear to be)  any Servlets mapped.

Are there any web applications in the appBase?

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Embedding with Tomcat 9

2020-02-18 Thread calder

On Tue, Feb 18, 2020, 14:12 Thad Humphries  wrote:

> I am trying to understand how to build and run an app from local with
> Tomcat 9 embedded using Java 8. I've started with this example written for
> Tomcat 7:
>
> https://www.oracle.com/webfolder/technetwork/tutorials/obe/java/basic_app_embedded_tomcat/basic_app-tomcat-embedded.html#overview
>
> I am able to get it to run with Tomcat 9 after a few changes to the pom.xml
> and one addition to the main() method:
>
> public static void main(String[] args) throws Exception {
>


  String contextPath = "" ;
>

May not be the issue, cause there's other code to consider, but should the
above line be

String contextPath = "/" ;


In the future, you should also check the full stack trace for clues


  String appBase = ".";
>   Tomcat tomcat = new Tomcat();
>   tomcat.setPort(Integer.valueOf(PORT.orElse("") ));
>   // next line added for Tomcat 9
>   tomcat.setConnector(tomcat.getConnector());
>
>   tomcat.setHostname(HOSTNAME.orElse("localhost"));
>   tomcat.getHost().setAppBase(appBase);
>   tomcat.addWebapp(contextPath, appBase);
>   tomcat.start();
>   tomcat.getServer().await();
> }
>
> However although this runs it returns a 404 on /employee. Why?
>
> I've tried variations on other Tomcat 9 examples (such as
> https://nkonev.name/post/101). There main() methods are considerably more
> involved, and I don't follow all that's going on. I've had no success. Some
> don't run, or, in the nkonev example earlier, JSPs aren't processed
> (probably because of "tomcat.setAddDefaultWebXmlToWebapp(false);" but if I
> commnent that out, the Jar won't run).
>
> What's the minimum to get the above main() to serve /employee?
>
>

Embedding with Tomcat 9

2020-02-18 Thread Thad Humphries

I am trying to understand how to build and run an app from local with
Tomcat 9 embedded using Java 8. I've started with this example written for
Tomcat 7:
https://www.oracle.com/webfolder/technetwork/tutorials/obe/java/basic_app_embedded_tomcat/basic_app-tomcat-embedded.html#overview

I am able to get it to run with Tomcat 9 after a few changes to the pom.xml
and one addition to the main() method:

public static void main(String[] args) throws Exception {
  String contextPath = "" ;
  String appBase = ".";
  Tomcat tomcat = new Tomcat();
  tomcat.setPort(Integer.valueOf(PORT.orElse("") ));
  // next line added for Tomcat 9
  tomcat.setConnector(tomcat.getConnector());

  tomcat.setHostname(HOSTNAME.orElse("localhost"));
  tomcat.getHost().setAppBase(appBase);
  tomcat.addWebapp(contextPath, appBase);
  tomcat.start();
  tomcat.getServer().await();
}

However although this runs it returns a 404 on /employee. Why?

I've tried variations on other Tomcat 9 examples (such as
https://nkonev.name/post/101). There main() methods are considerably more
involved, and I don't follow all that's going on. I've had no success. Some
don't run, or, in the nkonev example earlier, JSPs aren't processed
(probably because of "tomcat.setAddDefaultWebXmlToWebapp(false);" but if I
commnent that out, the Jar won't run).

What's the minimum to get the above main() to serve /employee?

-- 
"Hell hath no limits, nor is circumscrib'd In one self-place; but where we
are is hell, And where hell is, there must we ever be" --Christopher
Marlowe, *Doctor Faustus* (v. 111-13)

Re: Expect: 100-continue with filters vs valves

2020-02-18 Thread Michael Osipov

Am 2020-02-18 um 20:28 schrieb Mark Thomas:

On 18/02/2020 18:13, Michael Osipov wrote:

Am 2020-02-18 um 10:00 schrieb Mark Thomas:

On 17/02/2020 20:17, Michael Osipov wrote:

I have continued some tests on 8.5.51 with PUT requests and Expect: 100
continue header from HttpClient 5.0.

I have noticed that the very same code code fragment

What code fragment?

My bad, here it is:

Got it - I think. Let me re-phrase to see if I understand correctly.

You have a code fragment that issues a redirect.

The app submits a request with an header "Expect: 100-continue"

With the valve the sequence is:
- request
- redirect
- request
- 100 Continue
- response

With the filter the sequence is:
- request
- 100 Continue
- redirect (and body will be swallowed)
- request
- 100 Continue
- response

Exactly!

The questions is "Why the difference?" as the Filter is less efficient.
It ends up sending the body twice.

The answer is that Tomcat has to provide the "100 Continue" response
since there isn't a Servlet API for the app to do so. It does this as
the final act in the Context's pipeline (valve collection). That means
it happens after any Engine/Host/Context Valves you have configured but
before any Filters.

This enhancement request would help:
https://bz.apache.org/bugzilla/show_bug.cgi?id=57661

but it would need to be made optional as it will add a delay to the
request processing in some circumstances.

Now this makes sense. This basically means that something like this [1]
cannot efficiently implemented w/o using a valve?

If you say this is also a limitation in the Servlet API, it is worth to
raise that as a clarification point?

It might be worth adding to docs/config/valve.html when a valve is more
approriate than a filter. This is clearly a pitfall for such a case.

Thanks for the clarification.

[1]
https://github.com/csviri/bodylimiter/blob/master/src/main/java/com/csviri/security/filter/bodylength/RequestMessageBodyLengthLimitFilter.java

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Expect: 100-continue with filters vs valves

On 18/02/2020 18:13, Michael Osipov wrote:
> Am 2020-02-18 um 10:00 schrieb Mark Thomas:
>> On 17/02/2020 20:17, Michael Osipov wrote:
>>> I have continued some tests on 8.5.51 with PUT requests and Expect: 100
>>> continue header from HttpClient 5.0.
>>>
>>> I have noticed that the very same code code fragment
>>
>> What code fragment?
> 
> My bad, here it is:

Got it - I think. Let me re-phrase to see if I understand correctly.

You have a code fragment that issues a redirect.

The app submits a request with an header "Expect: 100-continue"

With the valve the sequence is:
- request
- redirect
- request
- 100 Continue
- response

With the filter the sequence is:
- request
- 100 Continue
- redirect (and body will be swallowed)
- request
- 100 Continue
- response

The questions is "Why the difference?" as the Filter is less efficient.
It ends up sending the body twice.

The answer is that Tomcat has to provide the "100 Continue" response
since there isn't a Servlet API for the app to do so. It does this as
the final act in the Context's pipeline (valve collection). That means
it happens after any Engine/Host/Context Valves you have configured but
before any Filters.

This enhancement request would help:
https://bz.apache.org/bugzilla/show_bug.cgi?id=57661

but it would need to be made optional as it will add a delay to the
request processing in some circumstances.

Mark


> 
> Filter:
>> @Override
>> public void doFilter(ServletRequest req, ServletResponse resp,
>> FilterChain chain)
>>     throws IOException, ServletException {
>>
>>     HttpServletRequest request = (HttpServletRequest) req;
>>     HttpServletResponse response = (HttpServletResponse) resp;
>>
>>     System.out.print(request.getPathInfo() + " ");
>>
>>     if (!request.getServletPath().startsWith("/redirected")) {
>>     String location = request.getContextPath() +
>> "/redirected/repo" + request.getPathInfo();
>>    
>> response.setStatus(HttpServletResponse.SC_TEMPORARY_REDIRECT);
>>     response.setHeader("Location", location);
>>     System.out.println("REDIRECT");
>>     return;
>>     }
>>
>>     chain.doFilter(request, response);
>>
>> }
> 
> 
> Valve:
>> @Override
>> public void invoke(Request req, Response resp) throws IOException,
>> ServletException {
>>
>>     HttpServletRequest request = (HttpServletRequest) req;
>>     HttpServletResponse response = (HttpServletResponse) resp;
>>
>>     System.out.print(request.getPathInfo() + " ");
>>
>>     if (!request.getServletPath().startsWith("/redirected")) {
>>     String location = request.getContextPath() +
>> "/redirected/repo" + request.getPathInfo();
>>    
>> response.setStatus(HttpServletResponse.SC_TEMPORARY_REDIRECT);
>>     response.setHeader("Location", location);
>>     System.out.println("REDIRECT");
>>     return;
>>     }
>>
>>     getNext().invoke(req, resp);
>>
>> }
> 
> Nothing fancy.
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Expect: 100-continue with filters vs valves

2020-02-18 Thread Michael Osipov


Am 2020-02-18 um 10:00 schrieb Mark Thomas:

On 17/02/2020 20:17, Michael Osipov wrote:

I have continued some tests on 8.5.51 with PUT requests and Expect: 100
continue header from HttpClient 5.0.

I have noticed that the very same code code fragment


What code fragment?


My bad, here it is:

Filter:

@Override
public void doFilter(ServletRequest req, ServletResponse resp, 
FilterChain chain)
throws IOException, ServletException {

HttpServletRequest request = (HttpServletRequest) req;
HttpServletResponse response = (HttpServletResponse) resp;

System.out.print(request.getPathInfo() + " ");

if (!request.getServletPath().startsWith("/redirected")) {
String location = request.getContextPath() + 
"/redirected/repo" + request.getPathInfo();

response.setStatus(HttpServletResponse.SC_TEMPORARY_REDIRECT);
response.setHeader("Location", location);
System.out.println("REDIRECT");
return;
}

chain.doFilter(request, response);

}



Valve:

@Override
public void invoke(Request req, Response resp) throws IOException, 
ServletException {

HttpServletRequest request = (HttpServletRequest) req;
HttpServletResponse response = (HttpServletResponse) resp;

System.out.print(request.getPathInfo() + " ");

if (!request.getServletPath().startsWith("/redirected")) {
String location = request.getContextPath() + 
"/redirected/repo" + request.getPathInfo();

response.setStatus(HttpServletResponse.SC_TEMPORARY_REDIRECT);
response.setHeader("Location", location);
System.out.println("REDIRECT");
return;
}

getNext().invoke(req, resp);

}


Nothing fancy.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 8.5.51 >> Use AJP Connector >> 403

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

John,

On 2/18/20 11:47, John Larsen wrote:
> It doesn't work otherwise. Before you guys changed the AJP we
> always used localhost for host in workers.
localhost and 127.0.0.1 and/or :: should all be synonyms of each other.

If you used to use (the default) "all interfaces" as the "address" of
the  and that changed to (the new default) "localhost" then
you should get a connector bound to a different interface, but
"localhost" from the client should still be the same thing.

The only thing I can think of is that "localhost" in the JVM might be
using 127.0.0.1 while the reverse proxy might resolve that to :: 9IPv4
versus IPv6 preference).

In that case, changing "localhost" to "127.0.0.1" makes it clear you
want to use IPv4 no matter what.

- -chris

> On Tue, Feb 18, 2020 at 9:27 AM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> John,
>
> On 2/18/20 07:49, John Larsen wrote:
 Worker host also needs to be 127.0.0.1 in your mod_jk
 workers.properties file.  That is if you were using
 host=localhost previously.
>
> Why?
>
> -chris
>
 On Tue, Feb 18, 2020 at 5:36 AM Friderike Hofmeister <
 friderike.hofmeis...@mbsupport.de> wrote:

> Hi,
>
> for our application we have to use the AJP protocol and so
> I understand with Tomcat 8.5.51 we have to configure the
> AJP connector as follows:
>
>  address="127.0.0.1" redirectPort="8443"
> secretRequired="false" secret="" />
>
> With this browser error message changed to "403 -- Der
> Server hat die Anfrage verstanden, verbietet aber eine
> Autoriesierung."
>
> So, probably we have to use the attribute
> allowedRequestAttributesPattern as well. But how? The
> documentation gives no example and the description there
> does not give me any idea how to use it.
>
> Regards and thanks in advance,
>
> Friderike Hofmeister DBA
>
> mb Support GmbH Friedenstr. 18 D-93053 Regensburg
>
> Tel.: +49 941 94 260-0 Hotline: +49 941 94 260-123 Fax: +49
> 941 94 260-111 E-Mail: friderike.hofmeister @mbsupport.de
>
> Web: www.mbsupport.de (http://www.mbsupport.de/) Sitz der
> Gesellschaft: Regensburg
>
> Geschäftsführer: Martin Böddecker Handelsregister:
> Amtsgericht Regensburg HRB 6469 Ust-IdNr. DE 8138 78197
>
> Hinweise zur Verarbeitung Ihrer personenbezogenen Daten:
> Verantwortlich für die Verarbeitung Ihrer personenbezogenen
> Daten im Rahmen des vorliegenden Kontakts ist die mb
> Support GmbH. Weitere Informationen zur Verarbeitung Ihrer
> Daten, insbesondere zu den Ihnen zustehenden Rechten,
> können Sie unserer Webseite unter
> https://mbsupport.de/index.php/datenschutz entnehmen oder
> auf jedem anderen Wege unter den o.g. Kontaktdaten bei uns
> erfragen.
>
> E-Mail Disclaimer Der Inhalt dieser E-Mail ist
> ausschließlich für den bezeichneten Adressaten bestimmt.
> Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder
> dessen Vertreter sein sollten, so beachten Sie bitte, dass
> jede Form der Kenntnisnahme, Veröffentlichung,
> Vervielfältigung oder Weitergabe des Inhalts dieser E-Mail
> unzulässig ist. Wir bitten Sie, sich in diesem Fall mit dem
> Absender der E-Mail in Verbindung zu setzen. The
> information contained in this email is intended solely for
> the addressee. Access to this email by anyone else is
> unauthorized. If you are not the intended recipient, any
> form of disclosure, reproduction, distribution or any
> action taken or refrained from in reliance on it, is
> prohibited and may be unlawful. Please notify the sender
> immediately.
>
> --
- ---
>
>
>
>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail:
> users-h...@tomcat.apache.org
>
>

>>
>> -
>>
>>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5MKNEACgkQHPApP6U8
pFiKWg/+PiPD64J994udCDcLJbw0GFpPAvKhsXUvG3rqbrQakTr4XFQcM2Qj1Gf3
Zt4D78peTv+o/1KvLDcDuYqjVsCyGu2e2KMpc1cFtabZPFh22tl2MpmQXV6InE95
qju7evsXGkwHoS3CHeMq2yKPnIG6F3GCL+BbprGkk13spUBr2xbXNI5FxYT+wBkP
Svd0JAdPrdY+kRMzQWhRtgr0KTuMzsdfPBS9ARtEfuHHL7ANCPx6ZNdOpiKzZb50
nnGvUroYub9bPie5pzstWAhCEK3wtIAUn6c296Te3rwuFdxuYAZXqPrqYKINJEyc
pYS1TGOP0lJngMTu1LsRDLGJ7+JnQ9klpGRXna35tKQjpaTAJTYvoPAJxpi48DNU
wORtEgpMI5Qrt7CrScX3EswqtzzlesAKnhVGybgY1FTYUkJmAp67yOFtTQwns2dB
z5e5kXN1z55NQVW550YXlmKnS95XiJ6Nr8xiO3NmRu+6faET6yW1xO6R86Pbt3XP
EFxMfZXECX7ltfero6U/AGYBlPbuIhjZQjIS8sBGpEJdboSuwFacn5CvGgMs7zi/
sGt/VE

Re: Enhancement: New option 'persistAuthentication' for session manager

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Carsten,

On 2/18/20 12:47, Carsten Klein wrote:
> Hi there,
>
> most of the issues discussed with/suggested by Mark Thomas should
> be in place now. The renamed PR should now show a much better code
> basis for further discussions.
>
>> b) Please add a changelog entry for this addition.
>
> Still looking for the change log file...

It's a little hidden:

webapps/docs/changelog.xml

Instructions and tons of examples are in the file.

Thanks for working on this.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5MKBcACgkQHPApP6U8
pFh4vRAAq74IrpIpolmt5pbOd+ORM4CZoCA63h5oI6u68o5vce/qia6N0Xeb3hG9
lL/fv+N4w8w3c/B0Hyi3I2oU3Eg9D3Ghc0/dhkSkMkQpEq1f0jrkYHqznk/tN4Ad
rpNyOKXtRepYqPkmQdZzbtKh6fTsdl4J8vHhWD5aH25143+7g7e8caEeypdPGz4Y
k++P/z0TV9IMy+ufHlH0ZUS03NiN171WgB6UP1Ff1NF4biVAiWermUiftDYIQVU3
P01DqUz2hDhLp/LJkKOQGTeOY3/bxhgv6A1N9z4FybG/KEJC6bLf1Q+eg9nUtjDW
KIdVXUYA0E+zwHPhTZpKDOj0efZC/c28woGluh3WX/1HoI12WjPBt7qe4hUhw/ZJ
WLrRtEXbmDcNPw0Z+sJShccMpxQKARFnozKA8gCM13Vb3r3WW57lCwQ3VHsKwXLy
5Rk7IbufMdtm2NGY8XQcT/2X4VX0J9l4loJYB8UEQd0TLJzMWAD2mFR/GafgSlne
KHVuNokSL47/kkQMJexfHg8N3cqThEQ/GD6Hja4Nd5yfWYgwbeUuaOJBpWThaUvW
4qFZd0mvztb+UjzYHBt6n0kWyRgmJxWdEv6zt/XgQJxNrOIQmmQ+NaajelCwMnho
MT8j4OAdvsh+Nt+GTEqsUjGX2aEnLfVrlXX2OOCFayiMMCqFXrA=
=mD7g
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Enhancement: New option 'persistAuthentication' for session manager


Hi there,

most of the issues discussed with/suggested by Mark Thomas should be in 
place now. The renamed PR should now show a much better code basis for 
further discussions.



b) Please add a changelog entry for this addition.


Still looking for the change log file...

Carsten

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Enhancement: New option 'persistAuthentication' for session manager





j) At a minimum, new Manager attributes need to be added here:
https://github.com/apache/tomcat/blob/master/webapps/docs/config/manager.xml


Here's an online preview of the updated Manger documentation:

http://office.datagis.com/pub/tomcat-9.0.x/docs/config/manager.html

These are the changes:

- added persistAuthentication for both StandardManager and PersistentManager

- updated default regular expression pattern for 
sessionAttributeValueClassNameFilter (both StandardManager and 
PersistentManager)


- added some notes under Special Features \ Persistence Across Restarts

Native speakers (English!) are encouraged to drop some comments focusing 
on language and translation... :-)


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 8.5.51 >> Use AJP Connector >> 403

2020-02-18 Thread John Larsen

It doesn't work otherwise. Before you guys changed the AJP we always used
locahost for host in workers.

John Larsen



On Tue, Feb 18, 2020 at 9:27 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> John,
>
> On 2/18/20 07:49, John Larsen wrote:
> > Worker host also needs to be 127.0.0.1 in your mod_jk
> > workers.properties file.  That is if you were using host=localhost
> > previously.
>
> Why?
>
> - -chris
>
> > On Tue, Feb 18, 2020 at 5:36 AM Friderike Hofmeister <
> > friderike.hofmeis...@mbsupport.de> wrote:
> >
> >> Hi,
> >>
> >> for our application we have to use the AJP protocol and so I
> >> understand with Tomcat 8.5.51 we have to configure the AJP
> >> connector as follows:
> >>
> >>  >> redirectPort="8443" secretRequired="false" secret="" />
> >>
> >> With this browser error message changed to "403 -- Der Server hat
> >> die Anfrage verstanden, verbietet aber eine Autoriesierung."
> >>
> >> So, probably we have to use the attribute
> >> allowedRequestAttributesPattern as well. But how? The
> >> documentation gives no example and the description there does not
> >> give me any idea how to use it.
> >>
> >> Regards and thanks in advance,
> >>
> >> Friderike Hofmeister DBA
> >>
> >> mb Support GmbH Friedenstr. 18 D-93053 Regensburg
> >>
> >> Tel.: +49 941 94 260-0 Hotline: +49 941 94 260-123 Fax: +49 941
> >> 94 260-111 E-Mail: friderike.hofmeister @mbsupport.de
> >>
> >> Web: www.mbsupport.de (http://www.mbsupport.de/) Sitz der
> >> Gesellschaft: Regensburg
> >>
> >> Geschäftsführer: Martin Böddecker Handelsregister: Amtsgericht
> >> Regensburg HRB 6469 Ust-IdNr. DE 8138 78197
> >>
> >> Hinweise zur Verarbeitung Ihrer personenbezogenen Daten:
> >> Verantwortlich für die Verarbeitung Ihrer personenbezogenen Daten
> >> im Rahmen des vorliegenden Kontakts ist die mb Support GmbH.
> >> Weitere Informationen zur Verarbeitung Ihrer Daten, insbesondere
> >> zu den Ihnen zustehenden Rechten, können Sie unserer Webseite
> >> unter https://mbsupport.de/index.php/datenschutz entnehmen oder
> >> auf jedem anderen Wege unter den o.g. Kontaktdaten bei uns
> >> erfragen.
> >>
> >> E-Mail Disclaimer Der Inhalt dieser E-Mail ist ausschließlich für
> >> den bezeichneten Adressaten bestimmt. Wenn Sie nicht der
> >> vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein
> >> sollten, so beachten Sie bitte, dass jede Form der Kenntnisnahme,
> >> Veröffentlichung, Vervielfältigung oder Weitergabe des Inhalts
> >> dieser E-Mail unzulässig ist. Wir bitten Sie, sich in diesem
> >> Fall mit dem Absender der E-Mail in Verbindung zu setzen. The
> >> information contained in this email is intended solely for the
> >> addressee. Access to this email by anyone else is unauthorized.
> >> If you are not the intended recipient, any form of disclosure,
> >> reproduction, distribution or any action taken or refrained from
> >> in reliance on it, is prohibited and may be unlawful. Please
> >> notify the sender immediately.
> >>
> >> -
> >>
> >>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5MC2MACgkQHPApP6U8
> pFgzqRAAkDvXVrBRgT8soWBKRNkYqaYdzdEWmX2IZWFj9R2+peYv95YDGRaxiPC7
> i295iVfg5U6JDChgWjm5epQc4wN3KJSYzg3ChskJ8S/mMEiqn9+Yeonmvhdb3rZb
> yiu8GB+bQgtfzp38fTzxugfM0B75vitvfZh7Tc5fkLLRg3EhC5J1gemc0hq+jXfs
> 0ezBUV/tghJdG3P/Xc0b7aMvkFJKlEXdyRaWNOUJ1x68LsTkc/2AofNB0WKTlYUb
> ysZdPMmCVBRCZaYfexVYU7xB3Dfmmnk+38Y18UJIupcjE9SBtqp7Z6hjdh9icY/H
> 2nc8YZxBI1V2Z+Y7+OxLjXc0BFK1rQDvUNi/FUraUjKnV+l6hPBFgVd8waX/FJoZ
> Iugy+ds55dYGgViM8NdWqzVf302fHhOpFHmlbEFmPjB55yfqU4c7qMfWS26wFzsV
> PQh3r0g2GJbXS1UitXBVrya50/eEQLI31CYcn5+tFGPtvZFfUMmHx/Gpc5aUr1io
> FiZuxbb+KX8EC64u+4lWDDIVvg1vyaBdASU+39OSmir4hmWNELZD6czXIUkLCGyu
> 7/bOUgFGiUIP44SehRwCT6aR0gq0buLvGijsyeSSFreozaCXbW0UnfwtP3y1i6Y7
> N9zu0Xm6QGVSrDWbpUSjmAoqUy1woSxKvuhqKwNMiILdGJn2Xhk=
> =rWyG
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Enhancement: New option 'persistAuthentication' for session manager

2020-02-18 Thread Jonathan S. Fisher

https://github.com/cklein05/tomcat/pull/1/files

Remy:  Thank you for the feedback, but please see the other threads about
this. The feature is not there right now because not everyone can/wants to
use the Delta Session Manager. For instance, we do _not_ want a p2p
architecture as they create scalability problems with the one-to-many
problem. The session boils down to a key-value store, and there are some
very nice network enabled key-value stores in existence; cassandra, redis,
couchdb, memcached, et all. Tomcat's point-to-point replication options
aren't sufficient in many cases, which is why there ought to be an option
to allow this.

For older versions of tomcat, I'd suggest adding an additional option that
causes GenericPrincipal to drop the password after authentication is
complete, by default if persistAuthentication is enabled, which alleviates
your concern.

On Tue, Feb 18, 2020 at 10:13 AM Carsten Klein  wrote:

> > Open the pull request in your own fork... this link should work:
> >
> https://github.com/cklein05/tomcat/compare/cklein05:master...cklein05:session-manager-persist-authentication?expand=1
>
> Done.
>
> Carsten
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 
Jonathan | exabr...@gmail.com
Pessimists, see a jar as half empty. Optimists, in contrast, see it as half
full.
Engineers, of course, understand the glass is twice as big as it needs to
be.

Re: Tomcat 8.5.51 >> Use AJP Connector >> 403

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

John,

On 2/18/20 07:49, John Larsen wrote:
> Worker host also needs to be 127.0.0.1 in your mod_jk
> workers.properties file.  That is if you were using host=localhost
> previously.

Why?

- -chris

> On Tue, Feb 18, 2020 at 5:36 AM Friderike Hofmeister <
> friderike.hofmeis...@mbsupport.de> wrote:
>
>> Hi,
>>
>> for our application we have to use the AJP protocol and so I
>> understand with Tomcat 8.5.51 we have to configure the AJP
>> connector as follows:
>>
>> > redirectPort="8443" secretRequired="false" secret="" />
>>
>> With this browser error message changed to "403 -- Der Server hat
>> die Anfrage verstanden, verbietet aber eine Autoriesierung."
>>
>> So, probably we have to use the attribute
>> allowedRequestAttributesPattern as well. But how? The
>> documentation gives no example and the description there does not
>> give me any idea how to use it.
>>
>> Regards and thanks in advance,
>>
>> Friderike Hofmeister DBA
>>
>> mb Support GmbH Friedenstr. 18 D-93053 Regensburg
>>
>> Tel.: +49 941 94 260-0 Hotline: +49 941 94 260-123 Fax: +49 941
>> 94 260-111 E-Mail: friderike.hofmeister @mbsupport.de
>>
>> Web: www.mbsupport.de (http://www.mbsupport.de/) Sitz der
>> Gesellschaft: Regensburg
>>
>> Geschäftsführer: Martin Böddecker Handelsregister: Amtsgericht
>> Regensburg HRB 6469 Ust-IdNr. DE 8138 78197
>>
>> Hinweise zur Verarbeitung Ihrer personenbezogenen Daten:
>> Verantwortlich für die Verarbeitung Ihrer personenbezogenen Daten
>> im Rahmen des vorliegenden Kontakts ist die mb Support GmbH.
>> Weitere Informationen zur Verarbeitung Ihrer Daten, insbesondere
>> zu den Ihnen zustehenden Rechten, können Sie unserer Webseite
>> unter https://mbsupport.de/index.php/datenschutz entnehmen oder
>> auf jedem anderen Wege unter den o.g. Kontaktdaten bei uns
>> erfragen.
>>
>> E-Mail Disclaimer Der Inhalt dieser E-Mail ist ausschließlich für
>> den bezeichneten Adressaten bestimmt. Wenn Sie nicht der
>> vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein
>> sollten, so beachten Sie bitte, dass jede Form der Kenntnisnahme,
>> Veröffentlichung, Vervielfältigung oder Weitergabe des Inhalts
>> dieser E-Mail unzulässig ist. Wir bitten Sie, sich in diesem
>> Fall mit dem Absender der E-Mail in Verbindung zu setzen. The
>> information contained in this email is intended solely for the
>> addressee. Access to this email by anyone else is unauthorized.
>> If you are not the intended recipient, any form of disclosure,
>> reproduction, distribution or any action taken or refrained from
>> in reliance on it, is prohibited and may be unlawful. Please
>> notify the sender immediately.
>>
>> -
>>
>>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5MC2MACgkQHPApP6U8
pFgzqRAAkDvXVrBRgT8soWBKRNkYqaYdzdEWmX2IZWFj9R2+peYv95YDGRaxiPC7
i295iVfg5U6JDChgWjm5epQc4wN3KJSYzg3ChskJ8S/mMEiqn9+Yeonmvhdb3rZb
yiu8GB+bQgtfzp38fTzxugfM0B75vitvfZh7Tc5fkLLRg3EhC5J1gemc0hq+jXfs
0ezBUV/tghJdG3P/Xc0b7aMvkFJKlEXdyRaWNOUJ1x68LsTkc/2AofNB0WKTlYUb
ysZdPMmCVBRCZaYfexVYU7xB3Dfmmnk+38Y18UJIupcjE9SBtqp7Z6hjdh9icY/H
2nc8YZxBI1V2Z+Y7+OxLjXc0BFK1rQDvUNi/FUraUjKnV+l6hPBFgVd8waX/FJoZ
Iugy+ds55dYGgViM8NdWqzVf302fHhOpFHmlbEFmPjB55yfqU4c7qMfWS26wFzsV
PQh3r0g2GJbXS1UitXBVrya50/eEQLI31CYcn5+tFGPtvZFfUMmHx/Gpc5aUr1io
FiZuxbb+KX8EC64u+4lWDDIVvg1vyaBdASU+39OSmir4hmWNELZD6czXIUkLCGyu
7/bOUgFGiUIP44SehRwCT6aR0gq0buLvGijsyeSSFreozaCXbW0UnfwtP3y1i6Y7
N9zu0Xm6QGVSrDWbpUSjmAoqUy1woSxKvuhqKwNMiILdGJn2Xhk=
=rWyG
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Enhancement: New option 'persistAuthentication' for session manager


Open the pull request in your own fork... this link should work:
https://github.com/cklein05/tomcat/compare/cklein05:master...cklein05:session-manager-persist-authentication?expand=1


Done.

Carsten

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 8.5.51 >> Use AJP Connector >> 403

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Friderike,

On 2/18/20 07:36, Friderike Hofmeister wrote:
> for our application we have to use the AJP protocol and so I
> understand with Tomcat 8.5.51 we have to configure the AJP
> connector as follows:
>
>  redirectPort="8443" secretRequired="false" secret="" />

You don't want secret="", which is different than leaving it unset.
Setting it to "" means it's set to an empty string.

I think you just want to remove the "secret" attribute altogether.

> With this browser error message changed to "403 -- Der Server hat
> die Anfrage verstanden, verbietet aber eine Autoriesierung."
Are there any other specific error messages in the logs?

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5MC80ACgkQHPApP6U8
pFh1vBAAyuLFmU/o1Q5Uy4PmDMIbalzXJZDyYR0k+f8R9fUjStoKAR41cf34RJq8
l0WPPQ2NTZFbm7RPHkKHj7wtDlv0cGSGgZdY9RZFbiAHr+vIvuJQu1NTn0Uqq+Xm
Us0Uf0sSURlYRiJh+k9uXf7LAmsp5QwzbUyPPv35B6RoW9tg7yzFQk6fmue2FmvH
ZxEtmm2UvwqYXnJX/eDoiBn08Dh+24T8SghVyXwHQhGn4AukjGJkxXtWprVJULvC
Jp54+kfaOWi+848nQhYFDq6gMwKsCzB/3zUgo3l7rW8p4G64dfZMSUez5W/9nKcF
3m0bQHeWQQ+ROFXQr6U8Mkq90pMpOFaSkfo2uOaqPAQ9VtjDitBLNbSE8yYtcX1r
FZOSmFM3p2cXIx5nHK0Lt2F8kBibTFJJByl/ZWJP75Ejpqt4HoITmNbSmzTc4iAK
xg/8zjlfxLGHH9QrVLwarPEcZAZ0mzk7P5JAaMmO20IKQWBpV0oZlFfVDns9ua6I
+gor9/+n4hSS3yAcZjzl1Io+bcDUYUFV2aQeywfvzU5Oh+rQxbASe7nCajx4W9lp
Yxn+asTrVi1NtOiteuRmkQKqFF+PQIMyJuyu0T9L+pkLA6oFtqv2YuBzDzV9e4vG
A2qK7B+ZMe3sAkFcS1HDInRXcnB12kC0FPOWVOVRqXvAb+PkUbs=
=AFTe
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Enhancement: New option 'persistAuthentication' for session manager

2020-02-18 Thread Jonathan S. Fisher

Open the pull request in your own fork... this link should work:
https://github.com/cklein05/tomcat/compare/cklein05:master...cklein05:session-manager-persist-authentication?expand=1

On Tue, Feb 18, 2020 at 6:42 AM Carsten Klein  wrote:

> Mark,
>
> > Please don't be put off by the number of comments and suggested changes.
> > I think the core idea is sound and meets a valid requirement that some
> > users have. To some extent, the volume of comments reflects that fact
> > I'm responding to a clear proposal and explanation. This is a good thing
> > in my eyes.
> >
> > In the order I thought of them:
> >
> > a) Please don't add author tags. ASF policy is not to add them. The ones
> > you see in the Tomcat codebase pre-date that policy. You will be
> > credited in the changelog. Which brings me on to...
>
> +1 OK
>
> >
> > b) Please add a changelog entry for this addition.
>
> Where is the changelog? Sorry, didn't find anything so far...
>
> >
> > c) Please add this new attribute to the documentation.
>
> +1 OK
>
> >
> >> 1. The new boolean option 'persistAuthentication' is implemented in
> >> ManagerBase and so can be configured for StandardManager or
> >> PersistentManager (defaults to false). Also added this to
> >> mbeans-descriptor.xml, so it's writable through JMX.
> >
> > +1
> >
> >> 2. That option is set for any new StandardSession upon creation (in
> >> method ManagerBase.createSession(String)). Once a session got this
> >> option, it's not being changed during the session's lifetime.
> >
> > d) Why do it this way as opposed to looking at the current setting in
> > the Manager when the session is persisted?
>
> That was my first idea, too. However, the StandardSession only knows a
> Manager (interface). I could have added the get/setPersistAuthentication
> methods to that interface (but didn't want to introduce such
> far-reaching changes) or need to test with instanceof for every session
> being written.
>
> Furthermore, some locking mechanism would be a good idea while sessions
> are stored, so that the option cannot be changed while a bunch of
> sessions is currently persisted (StandardManager synchronizes with
> sessions itself, however, PersistentManager does not). Actually a new
> lock monitor would be ideal.
>
> On the other side, one will likely not re-decide whether sessions shall
> be persisted or not from one day to another. I guess, that setting will
> remain quit constant for a certain installation, so my solution seemed
> not much worse.
>
> However, a simple instanceof ManageBase is also cheap and saves the
> setters and getters in StandardSession. Shall I refactor it acoordingly?
>
> >
> > e) I am very much against using system properties for configuration
> > except as a last resort. I don't see why PRINCIPAL_SERIALIZABLE_CHECK
> > can't be a property on the Manager. Although see g) below first.
>
> No longer needed, if a simple instanceof Serializable is enough. My idea
> was, that this option is true by default (a Principal is not a big class
> and the dry-run test should be fast enough). So, I did not see that this
> option was worth a config option (initially, that was just an internal
> constant).
>
> >
> >> 3. In StandardSession, method doWriteObject writes authentication
> >> information (authType and principal) only, if 'persistAuthentication' is
> >> true, the session is authenticated (authType or principal != null) and
> >> principal is serializable.
> >
> > f) Would the code be cleaner if these were always written and null
> > values used if authentication persistence is disabled?
>
> The idea was to be able to read the old-style object stream as well (a
> file created with the version without that enhancement). But, this can
> be achieved even without the Boolean tag. I will make that a bit more
> straight.
>
> >
> >> 4. The "is principal serializable" test is, by default, a deep
> >> (expensive?) check, which actually serializes the whole principal object
> >> to an ObjectOutputStream backed by a new NullInputStream, which just
> >> discards all bytes written. This check can be skipped by setting system
> >> property
> >> org.apache.catalina.session.StandardSession.PRINCIPAL_SERIALIZABLE_CHECK
> >> to false (defaults to true, however). If skipped, the principal is
> >> considered serializable if (principal instanceof Serializable). That's
> >> how the session's attribute values are checked for being serializable or
> >> not.
> >>
> >> However, that is odd, if such a serialized object has a child object
> >> which is not serializable. In that case, the ObjectOutputStream is left
> >> in an inconsistent state and no so called fatal exception code is
> >> written to the stream (that is, when reading such a stream, no
> >> WriteAbortedException is not thrown for such an error).
> >
> > g) The instanceof Serializable check should be sufficient. It a class
> > has that and then is not serializable that is a bug but not one I think
> > the Manager needs to protect itself from

Re: cloud cluster

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jon,

On 2/16/20 10:06, Jonathan Yom-Tov wrote:
> What kind of configuration do people usually use when deploying on
> a public cloud (e.g. AWS)? An auto-scaling cluster with session
> replication? A auto-scaling cluster with all sessions stored in an
> external cache?

Rémy Mucharat has recently been developing Kubernetes-based cluster
membership capabilities. So if you are using Kubernetes, you might
want to look into using that.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5MBi4ACgkQHPApP6U8
pFhhfhAAy4YicM2FAR23UnP6nVQxJdqRrSAQCxNVNMCxgUSYtIEeisb7pra3mIdS
dKU6YXAGdurKcSiL0LItwIR/GufzaVazM/vSBTZOrn+PUOPkGfbvAmO7jQbbmbxs
AP1NEruScgEVUNad/tUd6igG1iAjWFV7sZOcRIyXpEnyJxVIXujXWr+zmWi4caga
5MskwisPBN6gCTTDqUGzhGK+2HvMWgPp/WGYbReO2hSm11jmuuTIsLpOqTXodgKM
y77QtNIcxsQtfMLiL6pNfVbWRB4QlFpSKIUUetdcXHB8Njk3neBTlNdtzU+UjN2A
2dTtWFGbUYFKSRDD8T1QNbEc9biVBH2E7k73Fjo6lxYY0vt4UqCV8wA85h8A+Xxm
eOdRZt8LVAVC9pt+ctwtzDbB6CTWkQKJvYGUXyrEYfGA0ijAhXx118iI3DgXbpKf
J5eQQ1Ec85eABiwGjs6XqNOMn/6/9gn4Vjm+wKtSzVF+e563NNfMwGEM+GST8Q44
dQoXmju9MoNlgXE8EnuO5aDk1Xtjd3z7aGWxdVFRQ9M0V+PC+2/vVHRCw6vGUpIb
NCdqFMUB1jWU9jO0urdCzrMcFoyawmxRuLbDGOVCHlaXLfNTYfkstudhv2METqbV
oZrC2gt6NQWsRbp4W6vIzxP22T+oPcWJvaKteVLjxZrrO2Jfi0M=
=7qcU
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 8.5.51 >> Use AJP Connector >> 403

Sorry, but implementing mod_jk does not change anything.
Error 403 remains.

Possibly I made a mistake or do we need this attribute attribute 
allowedRequestAttributesPattern additionally?

Friderike Hofmeister

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 8.5.51 >> Use AJP Connector >> 403



And no need for this attribute allowedRequestAttributesPattern?

Friderike

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 8.5.51 >> Use AJP Connector >> 403

2020-02-18 Thread John Larsen

I assumed. That was the case for us when the ajp connector changed.

John

On Tue, Feb 18, 2020 at 5:59 AM Friderike Hofmeister <
friderike.hofmeis...@mbsupport.de> wrote:

> Hi John,
>
> currently we do not make usage of mod_jk and workers.properties.
> Does your post mean we have to implement it?
>
> Regards,
> Friderike Hofmeister
>
> >
>
> > John Larsen  hat am 18. Februar 2020 13:49
> geschrieben:
> >
> >
> > Worker host also needs to be 127.0.0.1 in your mod_jk workers.properties
> > file.  That is if you were using host=localhost previously.
> >
> > John Larsen
> >
> >
> > On Tue, Feb 18, 2020 at 5:36 AM Friderike Hofmeister <
> > friderike.hofmeis...@mbsupport.de> wrote:
> >
> > > Hi,
> > >
> > > for our application we have to use the AJP protocol and so I understand
> > > with Tomcat 8.5.51 we have to configure the AJP connector as follows:
> > >
> > >  > > protocol="AJP/1.3"
> > > address="127.0.0.1"
> > > redirectPort="8443"
> > > secretRequired="false"
> > > secret=""
> > > />
> > >
> > > With this browser error message changed to "403 -- Der Server hat die
> > > Anfrage verstanden, verbietet aber eine Autoriesierung."
> > >
> > > So, probably we have to use the attribute
> allowedRequestAttributesPattern
> > > as well. But how?
> > > The documentation gives no example and the description there does not
> give
> > > me any idea how to use it.
> > >
> > > Regards and thanks in advance,
> > >
> > > Friderike Hofmeister
> > > DBA
> > >
> > > mb Support GmbH
> > > Friedenstr. 18
> > > D-93053 Regensburg
> > >
> > > Tel.: +49 941 94 260-0
> > > Hotline: +49 941 94 260-123
> > > Fax: +49 941 94 260-111
> > > E-Mail: friderike.hofmeister @mbsupport.de
> > >
> > > Web: www.mbsupport.de (http://www.mbsupport.de/)
> > > Sitz der Gesellschaft: Regensburg
> > >
> > > Geschäftsführer: Martin Böddecker
> > > Handelsregister: Amtsgericht Regensburg HRB 6469
> > > Ust-IdNr. DE 8138 78197
> > >
> > > Hinweise zur Verarbeitung Ihrer personenbezogenen Daten: Verantwortlich
> > > für die Verarbeitung Ihrer personenbezogenen Daten im Rahmen des
> > > vorliegenden Kontakts ist die mb Support GmbH. Weitere Informationen
> zur
> > > Verarbeitung Ihrer Daten, insbesondere zu den Ihnen zustehenden
> Rechten,
> > > können Sie unserer Webseite unter
> > > https://mbsupport.de/index.php/datenschutz entnehmen oder auf jedem
> > > anderen Wege unter den o.g. Kontaktdaten bei uns erfragen.
> > >
> > > E-Mail Disclaimer
> > > Der Inhalt dieser E-Mail ist ausschließlich für den bezeichneten
> > > Adressaten bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser
> E-Mail
> > > oder dessen Vertreter sein sollten, so beachten Sie bitte, dass jede
> Form
> > > der Kenntnisnahme, Veröffentlichung, Vervielfältigung oder Weitergabe
> des
> > > Inhalts dieser E-Mail unzulässig ist. Wir bitten Sie, sich in diesem
> Fall
> > > mit dem Absender der E-Mail in Verbindung zu setzen.
> > > The information contained in this email is intended solely for the
> > > addressee. Access to this email by anyone else is unauthorized. If you
> are
> > > not the intended recipient, any form of disclosure,
> > > reproduction, distribution or any action taken or refrained from in
> > > reliance on it, is prohibited and may be unlawful. Please notify the
> sender
> > > immediately.
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > > For additional commands, e-mail: users-h...@tomcat.apache.org
> > >
> > >
>
-- 

John Larsen
__

Re: Tomcat 8.5.51 >> Use AJP Connector >> 403

Hi John,

currently we do not make usage of mod_jk and workers.properties.
Does your post mean we have to implement it?

Regards,
Friderike Hofmeister
 
> 

> John Larsen  hat am 18. Februar 2020 13:49 
> geschrieben:
> 
>  
> Worker host also needs to be 127.0.0.1 in your mod_jk workers.properties
> file.  That is if you were using host=localhost previously.
> 
> John Larsen
> 
> 
> On Tue, Feb 18, 2020 at 5:36 AM Friderike Hofmeister <
> friderike.hofmeis...@mbsupport.de> wrote:
> 
> > Hi,
> >
> > for our application we have to use the AJP protocol and so I understand
> > with Tomcat 8.5.51 we have to configure the AJP connector as follows:
> >
> >  > protocol="AJP/1.3"
> > address="127.0.0.1"
> > redirectPort="8443"
> > secretRequired="false"
> > secret=""
> > />
> >
> > With this browser error message changed to "403 -- Der Server hat die
> > Anfrage verstanden, verbietet aber eine Autoriesierung."
> >
> > So, probably we have to use the attribute allowedRequestAttributesPattern
> > as well. But how?
> > The documentation gives no example and the description there does not give
> > me any idea how to use it.
> >
> > Regards and thanks in advance,
> >
> > Friderike Hofmeister
> > DBA
> >
> > mb Support GmbH
> > Friedenstr. 18
> > D-93053 Regensburg
> >
> > Tel.: +49 941 94 260-0
> > Hotline: +49 941 94 260-123
> > Fax: +49 941 94 260-111
> > E-Mail: friderike.hofmeister @mbsupport.de
> >
> > Web: www.mbsupport.de (http://www.mbsupport.de/)
> > Sitz der Gesellschaft: Regensburg
> >
> > Geschäftsführer: Martin Böddecker
> > Handelsregister: Amtsgericht Regensburg HRB 6469
> > Ust-IdNr. DE 8138 78197
> >
> > Hinweise zur Verarbeitung Ihrer personenbezogenen Daten: Verantwortlich
> > für die Verarbeitung Ihrer personenbezogenen Daten im Rahmen des
> > vorliegenden Kontakts ist die mb Support GmbH. Weitere Informationen zur
> > Verarbeitung Ihrer Daten, insbesondere zu den Ihnen zustehenden Rechten,
> > können Sie unserer Webseite unter
> > https://mbsupport.de/index.php/datenschutz entnehmen oder auf jedem
> > anderen Wege unter den o.g. Kontaktdaten bei uns erfragen.
> >
> > E-Mail Disclaimer
> > Der Inhalt dieser E-Mail ist ausschließlich für den bezeichneten
> > Adressaten bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser E-Mail
> > oder dessen Vertreter sein sollten, so beachten Sie bitte, dass jede Form
> > der Kenntnisnahme, Veröffentlichung, Vervielfältigung oder Weitergabe des
> > Inhalts dieser E-Mail unzulässig ist. Wir bitten Sie, sich in diesem Fall
> > mit dem Absender der E-Mail in Verbindung zu setzen.
> > The information contained in this email is intended solely for the
> > addressee. Access to this email by anyone else is unauthorized. If you are
> > not the intended recipient, any form of disclosure,
> > reproduction, distribution or any action taken or refrained from in
> > reliance on it, is prohibited and may be unlawful. Please notify the sender
> > immediately.
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 8.5.51 >> Use AJP Connector >> 403

2020-02-18 Thread John Larsen

Worker host also needs to be 127.0.0.1 in your mod_jk workers.properties
file.  That is if you were using host=localhost previously.

John Larsen


On Tue, Feb 18, 2020 at 5:36 AM Friderike Hofmeister <
friderike.hofmeis...@mbsupport.de> wrote:

> Hi,
>
> for our application we have to use the AJP protocol and so I understand
> with Tomcat 8.5.51 we have to configure the AJP connector as follows:
>
>  protocol="AJP/1.3"
> address="127.0.0.1"
> redirectPort="8443"
> secretRequired="false"
> secret=""
> />
>
> With this browser error message changed to "403 -- Der Server hat die
> Anfrage verstanden, verbietet aber eine Autoriesierung."
>
> So, probably we have to use the attribute allowedRequestAttributesPattern
> as well. But how?
> The documentation gives no example and the description there does not give
> me any idea how to use it.
>
> Regards and thanks in advance,
>
> Friderike Hofmeister
> DBA
>
> mb Support GmbH
> Friedenstr. 18
> D-93053 Regensburg
>
> Tel.: +49 941 94 260-0
> Hotline: +49 941 94 260-123
> Fax: +49 941 94 260-111
> E-Mail: friderike.hofmeister @mbsupport.de
>
> Web: www.mbsupport.de (http://www.mbsupport.de/)
> Sitz der Gesellschaft: Regensburg
>
> Geschäftsführer: Martin Böddecker
> Handelsregister: Amtsgericht Regensburg HRB 6469
> Ust-IdNr. DE 8138 78197
>
> Hinweise zur Verarbeitung Ihrer personenbezogenen Daten: Verantwortlich
> für die Verarbeitung Ihrer personenbezogenen Daten im Rahmen des
> vorliegenden Kontakts ist die mb Support GmbH. Weitere Informationen zur
> Verarbeitung Ihrer Daten, insbesondere zu den Ihnen zustehenden Rechten,
> können Sie unserer Webseite unter
> https://mbsupport.de/index.php/datenschutz entnehmen oder auf jedem
> anderen Wege unter den o.g. Kontaktdaten bei uns erfragen.
>
> E-Mail Disclaimer
> Der Inhalt dieser E-Mail ist ausschließlich für den bezeichneten
> Adressaten bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser E-Mail
> oder dessen Vertreter sein sollten, so beachten Sie bitte, dass jede Form
> der Kenntnisnahme, Veröffentlichung, Vervielfältigung oder Weitergabe des
> Inhalts dieser E-Mail unzulässig ist. Wir bitten Sie, sich in diesem Fall
> mit dem Absender der E-Mail in Verbindung zu setzen.
> The information contained in this email is intended solely for the
> addressee. Access to this email by anyone else is unauthorized. If you are
> not the intended recipient, any form of disclosure,
> reproduction, distribution or any action taken or refrained from in
> reliance on it, is prohibited and may be unlawful. Please notify the sender
> immediately.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Enhancement: New option 'persistAuthentication' for session manager


Mark,


Please don't be put off by the number of comments and suggested changes.
I think the core idea is sound and meets a valid requirement that some
users have. To some extent, the volume of comments reflects that fact
I'm responding to a clear proposal and explanation. This is a good thing
in my eyes.

In the order I thought of them:

a) Please don't add author tags. ASF policy is not to add them. The ones
you see in the Tomcat codebase pre-date that policy. You will be
credited in the changelog. Which brings me on to...


+1 OK



b) Please add a changelog entry for this addition.


Where is the changelog? Sorry, didn't find anything so far...



c) Please add this new attribute to the documentation.


+1 OK




1. The new boolean option 'persistAuthentication' is implemented in
ManagerBase and so can be configured for StandardManager or
PersistentManager (defaults to false). Also added this to
mbeans-descriptor.xml, so it's writable through JMX.


+1


2. That option is set for any new StandardSession upon creation (in
method ManagerBase.createSession(String)). Once a session got this
option, it's not being changed during the session's lifetime.


d) Why do it this way as opposed to looking at the current setting in
the Manager when the session is persisted?


That was my first idea, too. However, the StandardSession only knows a 
Manager (interface). I could have added the get/setPersistAuthentication 
methods to that interface (but didn't want to introduce such 
far-reaching changes) or need to test with instanceof for every session 
being written.


Furthermore, some locking mechanism would be a good idea while sessions 
are stored, so that the option cannot be changed while a bunch of 
sessions is currently persisted (StandardManager synchronizes with 
sessions itself, however, PersistentManager does not). Actually a new 
lock monitor would be ideal.


On the other side, one will likely not re-decide whether sessions shall 
be persisted or not from one day to another. I guess, that setting will 
remain quit constant for a certain installation, so my solution seemed 
not much worse.


However, a simple instanceof ManageBase is also cheap and saves the 
setters and getters in StandardSession. Shall I refactor it acoordingly?




e) I am very much against using system properties for configuration
except as a last resort. I don't see why PRINCIPAL_SERIALIZABLE_CHECK
can't be a property on the Manager. Although see g) below first.


No longer needed, if a simple instanceof Serializable is enough. My idea 
was, that this option is true by default (a Principal is not a big class 
and the dry-run test should be fast enough). So, I did not see that this 
option was worth a config option (initially, that was just an internal 
constant).





3. In StandardSession, method doWriteObject writes authentication
information (authType and principal) only, if 'persistAuthentication' is
true, the session is authenticated (authType or principal != null) and
principal is serializable.


f) Would the code be cleaner if these were always written and null
values used if authentication persistence is disabled?


The idea was to be able to read the old-style object stream as well (a 
file created with the version without that enhancement). But, this can 
be achieved even without the Boolean tag. I will make that a bit more 
straight.





4. The "is principal serializable" test is, by default, a deep
(expensive?) check, which actually serializes the whole principal object
to an ObjectOutputStream backed by a new NullInputStream, which just
discards all bytes written. This check can be skipped by setting system
property
org.apache.catalina.session.StandardSession.PRINCIPAL_SERIALIZABLE_CHECK
to false (defaults to true, however). If skipped, the principal is
considered serializable if (principal instanceof Serializable). That's
how the session's attribute values are checked for being serializable or
not.

However, that is odd, if such a serialized object has a child object
which is not serializable. In that case, the ObjectOutputStream is left
in an inconsistent state and no so called fatal exception code is
written to the stream (that is, when reading such a stream, no
WriteAbortedException is not thrown for such an error).


g) The instanceof Serializable check should be sufficient. It a class
has that and then is not serializable that is a bug but not one I think
the Manager needs to protect itself from beyond catching and logging the
exception (and inserting null into the object stream).


+1 OK




5. A Boolean object is used as a tag/marker that determines, whether
authentication information is present id the stream or not. If none of
the above conditions are met, both authType and principal are not
serialized (than, only the initial Boolean false marker has been emitted
to the stream).

BTW, the Boolean false marker is not even required (if there is no
authentication information in the stream) since the reading code

Tomcat 8.5.51 >> Use AJP Connector >> 403

Hi,

for our application we have to use the AJP protocol and so I understand with 
Tomcat 8.5.51 we have to configure the AJP connector as follows:



With this browser error message changed to "403 -- Der Server hat die Anfrage 
verstanden, verbietet aber eine Autoriesierung."

So, probably we have to use the attribute allowedRequestAttributesPattern as 
well. But how?
The documentation gives no example and the description there does not give me 
any idea how to use it.

Regards and thanks in advance,

Friderike Hofmeister
DBA

mb Support GmbH 
Friedenstr. 18 
D-93053 Regensburg

Tel.: +49 941 94 260-0 
Hotline: +49 941 94 260-123 
Fax: +49 941 94 260-111 
E-Mail: friderike.hofmeister @mbsupport.de

Web: www.mbsupport.de (http://www.mbsupport.de/) 
Sitz der Gesellschaft: Regensburg 

Geschäftsführer: Martin Böddecker 
Handelsregister: Amtsgericht Regensburg HRB 6469 
Ust-IdNr. DE 8138 78197

Hinweise zur Verarbeitung Ihrer personenbezogenen Daten: Verantwortlich für die 
Verarbeitung Ihrer personenbezogenen Daten im Rahmen des vorliegenden Kontakts 
ist die mb Support GmbH. Weitere Informationen zur Verarbeitung Ihrer Daten, 
insbesondere zu den Ihnen zustehenden Rechten, können Sie unserer Webseite 
unter https://mbsupport.de/index.php/datenschutz entnehmen oder auf jedem 
anderen Wege unter den o.g. Kontaktdaten bei uns erfragen. 

E-Mail Disclaimer 
Der Inhalt dieser E-Mail ist ausschließlich für den bezeichneten Adressaten 
bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen 
Vertreter sein sollten, so beachten Sie bitte, dass jede Form der 
Kenntnisnahme, Veröffentlichung, Vervielfältigung oder Weitergabe des Inhalts 
dieser E-Mail unzulässig ist. Wir bitten Sie, sich in diesem Fall mit dem 
Absender der E-Mail in Verbindung zu setzen. 
The information contained in this email is intended solely for the addressee. 
Access to this email by anyone else is unauthorized. If you are not the 
intended recipient, any form of disclosure, reproduction, distribution or any 
action taken or refrained from in reliance on it, is prohibited and may be 
unlawful. Please notify the sender immediately.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Enhancement: New option 'persistAuthentication' for session manager


On Tue, Feb 18, 2020 at 9:19 AM Carsten Klein  wrote:


Rémy,



Can you describe an actual use case for this ? Without clustering, I

don't

understand why the auth persistence is useful at all [when using
clustering, the delta manager persists that auth information]. To be
honest, that's also the case for session persistence itself, which does

not

provide a QoS level that is still relevant today. But the feature is
already there [maybe it could be considered for removal in 10 actually

...].

Why is session persistence across restarts not still relevant today?
Tomcat, as well as likely any other servlet container, stops/starts a
context when actually a reload (aka reconfigure) action would be
required (I guess, that's specified servlet specs, right?).

A context needs to be completely restarted for any configuration change
(oh, we need to add a new allowed host to the CORS filter, etc.).
Restarting, and so loosing all runtime data (the session), makes this
simple stop/start approach (from a programmer's point of view) difficult
to use in a production environment. I often find myself doing such
configuration changes in the evening in order not to drop logged on
users (that's when I'd better enjoy some freetime *g*).

That's why I believe, that session persistence across restarts is
required still today. Of course, there may be frameworks, including
clustering, that can do a lot for you. However, I'm talking about
Tomcat, not other frameworks. Why shouldn't Tomcat on its own provide a
production-system-ready "reconfigure" action? It did in the past, why
dropping it? That feature seems not too buggy...

Also, for me, setting up a Tomcat cluster with at least two machines,
only for getting session persistence during reconfiguring the nodes
seems a bit overdrawn. In our setups we typically have one server
machine, serving between 10 and 50 users at a time. I just can't tell my
customer to double the hardware just in order to keep users logged on
while we are working on the configuration.



Maybe you think it's "overdrawn", but right now you have very poor QoS.
What happens while the webapp/server is away ? Do you think the user will
not see anything bad ? [aka: please don't do anything until the restart is
done ...] Plus what happens if you have 1s of sessions ? It gets slow
and some have complained about it in the past. Etc etc.


Rémy,

in our case, the app runs standalone in the browser and is fully AJAX 
driven, so, if the server restarts in some 10 seconds, the user does not 
even recognize. Maybe one or other request to the server (loading/saving 
some data) is slow, since it waits for the server to be up again. In 
very rare cases, it may run into a timeout, in which case the app comes 
up with a message box "Server is currently not available, please try 
again in some minutes."


BTW, session persistence can simply be disabled even today, by setting 
StandardManager's pathname to en empty string.


Yes, with 1s of sessions persistence may be a bottleneck (even with 
PersistentManager). However, actually, we do not have so many sessions.


Maybe that is the general point. There are so many scenarios, Tomcat is 
used in. So, who will actually really know, which features are good and 
which are bad? It always depends on the actual scenario. Of course, 
security is important and software vendors must ensure to publish secure 
(-by-default) software. I agree, that saving the principal to disk for 
some seconds may be a security risk for some apps and some people. 
That's why the new feature is configurable and defaults to off.


However, as a server admin, I'm able to secure the installation that 
way, so that nobody external is able to read such session files. Of 
course, with the root password, you are always able to do lot of bad 
things (includes attaching to the JVM and reading passwords directly 
from memory). So, when security is an issue, NOT saving passwords at all 
could be a first step :-p



That's not how things should happen today.


Whats your proposal? How should things happen today?






It may be the case, that today, many setups use WAR files, including
code and configuration, which are deployed at regular intervals or at
scheduled deploy times. However, that's not how we work. We like to be
able to react contemporary when a problem in a production system comes
up (our customers like that, too).

So, that's my plea for session persistence across restarts, as
implemented in recent versions. Nearly the same use case applies to
persisting authentication information as well.



The feature is there right now, so you're good ...




In our setups, we use the session mainly for authentication. The problem
that comes with not persisting authentication may not be obvious with
simple (browser driven) BASIC authentication, since the Browser sends
those Base64 encoded credentials with each request. Using session based
authentication (send credentials once and rely that your session rem

Re: Enhancement: New option 'persistAuthentication' for session manager

On 17/02/2020 17:31, Carsten Klein wrote:
> Hi there,
> 
> finally, I got my first Tomcat enhancement ready. You can view its code
> at my Tomcat fork on GitHub:
> 
> https://github.com/cklein05/tomcat/tree/session-manager-persist-authentication
> 
> 
> Before I'm opening an enhancement in Tomcat's Bugzilla, maybe, Mark and
> Christopher (or whoever else is interested), could you please have a
> quick look at the code?

I was going to write this at the end, but I decided it would be better
up front.

Please don't be put off by the number of comments and suggested changes.
I think the core idea is sound and meets a valid requirement that some
users have. To some extent, the volume of comments reflects that fact
I'm responding to a clear proposal and explanation. This is a good thing
in my eyes.

In the order I thought of them:

a) Please don't add author tags. ASF policy is not to add them. The ones
you see in the Tomcat codebase pre-date that policy. You will be
credited in the changelog. Which brings me on to...

b) Please add a changelog entry for this addition.

c) Please add this new attribute to the documentation.

> 1. The new boolean option 'persistAuthentication' is implemented in
> ManagerBase and so can be configured for StandardManager or
> PersistentManager (defaults to false). Also added this to
> mbeans-descriptor.xml, so it's writable through JMX.

+1

> 2. That option is set for any new StandardSession upon creation (in
> method ManagerBase.createSession(String)). Once a session got this
> option, it's not being changed during the session's lifetime.

d) Why do it this way as opposed to looking at the current setting in
the Manager when the session is persisted?

e) I am very much against using system properties for configuration
except as a last resort. I don't see why PRINCIPAL_SERIALIZABLE_CHECK
can't be a property on the Manager. Although see g) below first.

> 3. In StandardSession, method doWriteObject writes authentication
> information (authType and principal) only, if 'persistAuthentication' is
> true, the session is authenticated (authType or principal != null) and
> principal is serializable.

f) Would the code be cleaner if these were always written and null
values used if authentication persistence is disabled?

> 4. The "is principal serializable" test is, by default, a deep
> (expensive?) check, which actually serializes the whole principal object
> to an ObjectOutputStream backed by a new NullInputStream, which just
> discards all bytes written. This check can be skipped by setting system
> property
> org.apache.catalina.session.StandardSession.PRINCIPAL_SERIALIZABLE_CHECK
> to false (defaults to true, however). If skipped, the principal is
> considered serializable if (principal instanceof Serializable). That's
> how the session's attribute values are checked for being serializable or
> not.
> 
> However, that is odd, if such a serialized object has a child object
> which is not serializable. In that case, the ObjectOutputStream is left
> in an inconsistent state and no so called fatal exception code is
> written to the stream (that is, when reading such a stream, no
> WriteAbortedException is not thrown for such an error).

g) The instanceof Serializable check should be sufficient. It a class
has that and then is not serializable that is a bug but not one I think
the Manager needs to protect itself from beyond catching and logging the
exception (and inserting null into the object stream).

> 5. A Boolean object is used as a tag/marker that determines, whether
> authentication information is present id the stream or not. If none of
> the above conditions are met, both authType and principal are not
> serialized (than, only the initial Boolean false marker has been emitted
> to the stream).
> 
> BTW, the Boolean false marker is not even required (if there is no
> authentication information in the stream) since the reading code works
> fine without any Boolean in the stream. So emitting Boolean false for
> signalling "no auth info" is actually optional (we could consider
> omitting it).

h) See comment f).

> 6. When sessions are loaded, ManagerBase provides a
> org.apache.catalina.util.CustomObjectInputStream instance to read
> sessions from. That instance is configured with the session's
> sessionAttributeValueClassNamePattern property. This essentially defines
> the classes, session attribute values may consist of. This pattern
> defaults to "java\\.lang\\.(?:Boolean|Integer|Long|Number|String)", so
> only attributes with these simple types can be loaded from a session.
> 
> That filter pattern is only in effect, if a security manager is active,
> or if a pattern has been configured for the manager (e.g. in context.xml).
> 
> Currently, however, all session data (including its base properties like
> creationTime, isNew, isValid etc) is loaded with that filter mechanism
> in place. Since those so called 'scalar instance properties' actually
> only consist of those simple ty

Re: Enhancement: New option 'persistAuthentication' for session manager

2020-02-18 Thread Rémy Maucherat

On Tue, Feb 18, 2020 at 9:19 AM Carsten Klein  wrote:

> Rémy,
>
>
> > Can you describe an actual use case for this ? Without clustering, I
> don't
> > understand why the auth persistence is useful at all [when using
> > clustering, the delta manager persists that auth information]. To be
> > honest, that's also the case for session persistence itself, which does
> not
> > provide a QoS level that is still relevant today. But the feature is
> > already there [maybe it could be considered for removal in 10 actually
> ...].
>
> Why is session persistence across restarts not still relevant today?
> Tomcat, as well as likely any other servlet container, stops/starts a
> context when actually a reload (aka reconfigure) action would be
> required (I guess, that's specified servlet specs, right?).
>
> A context needs to be completely restarted for any configuration change
> (oh, we need to add a new allowed host to the CORS filter, etc.).
> Restarting, and so loosing all runtime data (the session), makes this
> simple stop/start approach (from a programmer's point of view) difficult
> to use in a production environment. I often find myself doing such
> configuration changes in the evening in order not to drop logged on
> users (that's when I'd better enjoy some freetime *g*).
>
> That's why I believe, that session persistence across restarts is
> required still today. Of course, there may be frameworks, including
> clustering, that can do a lot for you. However, I'm talking about
> Tomcat, not other frameworks. Why shouldn't Tomcat on its own provide a
> production-system-ready "reconfigure" action? It did in the past, why
> dropping it? That feature seems not too buggy...
>
> Also, for me, setting up a Tomcat cluster with at least two machines,
> only for getting session persistence during reconfiguring the nodes
> seems a bit overdrawn. In our setups we typically have one server
> machine, serving between 10 and 50 users at a time. I just can't tell my
> customer to double the hardware just in order to keep users logged on
> while we are working on the configuration.
>

Maybe you think it's "overdrawn", but right now you have very poor QoS.
What happens while the webapp/server is away ? Do you think the user will
not see anything bad ? [aka: please don't do anything until the restart is
done ...] Plus what happens if you have 1s of sessions ? It gets slow
and some have complained about it in the past. Etc etc.
That's not how things should happen today.


>
> It may be the case, that today, many setups use WAR files, including
> code and configuration, which are deployed at regular intervals or at
> scheduled deploy times. However, that's not how we work. We like to be
> able to react contemporary when a problem in a production system comes
> up (our customers like that, too).
>
> So, that's my plea for session persistence across restarts, as
> implemented in recent versions. Nearly the same use case applies to
> persisting authentication information as well.
>

The feature is there right now, so you're good ...


>
> In our setups, we use the session mainly for authentication. The problem
> that comes with not persisting authentication may not be obvious with
> simple (browser driven) BASIC authentication, since the Browser sends
> those Base64 encoded credentials with each request. Using session based
> authentication (send credentials once and rely that your session remains
> authenticated) is more modern and likely a bit more secure, right?
>
> However, in that scenario, it's really bad, if your authentication has
> gone after the context has been restarted. In that case, you may be
> forwarded to the login page (when using FORM authentication). In our
> case, our AJAX-style JavaScript client just logs you off and all your
> work is gone (that's like if your browser crashes occasionally and has
> no "restore previously opened tabs" feature...). In our case,
> authentication information is the only valuable data in the session (we
> don't save any attributes). So, isn't persisting authentication
> information (for the sake of completeness) a feature of its own?
>
> In other words, why not persisting authentication information? That data
> is the only data, that currently is NOT persisted. Why not? Comments in
> the code only mention, that authType and principal are transient. But
> why? If there is a session persistence feature in Tomcat, shouldn't it
> persist the session as a whole (at least, as much as possible)? Since
> recent versions of Tomcat's default GenericPrincipal do no longer save
> passwords, persisting authType and principal seems not being harmful to me.
>
> Again, session persistence across restarts is just a "workaround" for
> the missing "reconfigure" action. For me, it's the tribute for using the
> much simpler stop/start schema in servlet containers (in contrast to a
> real reconfigure action, which often tends to get quite complex).
> Typically, persisted sessions do not remain on di

Re: Expect: 100-continue with filters vs valves

On 17/02/2020 20:17, Michael Osipov wrote:
> I have continued some tests on 8.5.51 with PUT requests and Expect: 100
> continue header from HttpClient 5.0.
> 
> I have noticed that the very same code code fragment 

What code fragment?

> kicks in in the
> expect header evaluation when run as valve, but completely ignored when
> run in a filter. Tomcat will simply signal the client to continue with
> the request.
> 
> Valve:
>> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Proxy
>> auth state: UNCHALLENGED
>> [main] DEBUG org.apache.http.headers - http-outgoing-0 >> PUT
>> /bb/repo/my.file HTTP/1.1
>> [main] DEBUG org.apache.http.headers - http-outgoing-0 >>
>> Content-Length: 15
>> [main] DEBUG org.apache.http.headers - http-outgoing-0 >> Host:
>> localhost:8080
>> [main] DEBUG org.apache.http.headers - http-outgoing-0 >> Connection:
>> Keep-Alive
>> [main] DEBUG org.apache.http.headers - http-outgoing-0 >> User-Agent:
>> Apache-HttpClient/4.5.11 (Java/1.7.0_252)
>> [main] DEBUG org.apache.http.headers - http-outgoing-0 >> Expect:
>> 100-continue
>> [main] DEBUG org.apache.http.headers - http-outgoing-0 >>
>> Accept-Encoding: gzip,deflate
>> [main] DEBUG org.apache.http.wire - http-outgoing-0 >> "PUT
>> /bb/repo/my.file HTTP/1.1[\r][\n]"
>> [main] DEBUG org.apache.http.wire - http-outgoing-0 >>
>> "Content-Length: 15[\r][\n]"
>> [main] DEBUG org.apache.http.wire - http-outgoing-0 >> "Host:
>> localhost:8080[\r][\n]"
>> [main] DEBUG org.apache.http.wire - http-outgoing-0 >> "Connection:
>> Keep-Alive[\r][\n]"
>> [main] DEBUG org.apache.http.wire - http-outgoing-0 >> "User-Agent:
>> Apache-HttpClient/4.5.11 (Java/1.7.0_252)[\r][\n]"
>> [main] DEBUG org.apache.http.wire - http-outgoing-0 >> "Expect:
>> 100-continue[\r][\n]"
>> [main] DEBUG org.apache.http.wire - http-outgoing-0 >>
>> "Accept-Encoding: gzip,deflate[\r][\n]"
>> [main] DEBUG org.apache.http.wire - http-outgoing-0 >> "[\r][\n]"
>> [main] DEBUG org.apache.http.wire - http-outgoing-0 << "HTTP/1.1 307
>> [\r][\n]"
>> [main] DEBUG org.apache.http.wire - http-outgoing-0 << "Location:
>> /bb/redirected/repo/my.file[\r][\n]"
>> [main] DEBUG org.apache.http.wire - http-outgoing-0 <<
>> "Content-Length: 0[\r][\n]"
>> [main] DEBUG org.apache.http.wire - http-outgoing-0 << "Date: Mon, 17
>> Feb 2020 20:11:54 GMT[\r][\n]"
>> [main] DEBUG org.apache.http.wire - http-outgoing-0 << "Connection:
>> close[\r][\n]"
>> [main] DEBUG org.apache.http.wire - http-outgoing-0 << "[\r][\n]"
>> [main] DEBUG org.apache.http.headers - http-outgoing-0 << HTTP/1.1 307
>> [main] DEBUG org.apache.http.headers - http-outgoing-0 << Location:
>> /bb/redirected/repo/my.file
>> [main] DEBUG org.apache.http.headers - http-outgoing-0 <<
>> Content-Length: 0
>> [main] DEBUG org.apache.http.headers - http-outgoing-0 << Date: Mon,
>> 17 Feb 2020 20:11:54 GMT
>> [main] DEBUG org.apache.http.headers - http-outgoing-0 << Connection:
>> close
>> [main] DEBUG
>> org.apache.http.impl.conn.DefaultManagedHttpClientConnection -
>> http-outgoing-0: Close connection
>> [main] DEBUG org.apache.http.impl.execchain.MainClientExec -
>> Connection discarded
>> [main] DEBUG
>> org.apache.http.impl.conn.PoolingHttpClientConnectionManager -
>> Connection released: [id: 0][route: {}->http://localhost:8080][total
>> available: 0; route allocated: 0 of 2; total allocated: 0 of 20]
>> [main] DEBUG org.apache.http.impl.execchain.RedirectExec - Redirecting
>> to 'http://localhost:8080/bb/redirected/repo/my.file' via
>> {}->http://localhost:8080
>> [main] DEBUG org.apache.http.client.protocol.RequestAddCookies -
>> CookieSpec selected: default
>> [main] DEBUG org.apache.http.client.protocol.RequestAuthCache - Auth
>> cache not set in the context
>> [main] DEBUG
>> org.apache.http.impl.conn.PoolingHttpClientConnectionManager -
>> Connection request: [route: {}->http://localhost:8080][total
>> available: 0; route allocated: 0 of 2; total allocated: 0 of 20]
>> [main] DEBUG
>> org.apache.http.impl.conn.PoolingHttpClientConnectionManager -
>> Connection leased: [id: 1][route: {}->http://localhost:8080][total
>> available: 0; route allocated: 1 of 2; total allocated: 1 of 20]
>> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Opening
>> connection {}->http://localhost:8080
>> [main] DEBUG
>> org.apache.http.impl.conn.DefaultHttpClientConnectionOperator -
>> Connecting to localhost/127.0.0.1:8080
>> [main] DEBUG
>> org.apache.http.impl.conn.DefaultHttpClientConnectionOperator -
>> Connection established 127.0.0.1:57395<->127.0.0.1:8080
>> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Executing
>> request PUT /bb/redirected/repo/my.file HTTP/1.1
>> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Target
>> auth state: UNCHALLENGED
>> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Proxy
>> auth state: UNCHALLENGED
>> [main] DEBUG org.apache.http.headers - http-outgoing-1 >> PUT
>> /bb/redirected/repo/my.file HTTP/1.1
>> [main] DEBUG org.apache.http.head

Re: Tomcat responding 500 instead of 408

On 17/02/2020 18:39, Michael Osipov wrote:
> Am 2020-02-17 um 16:47 schrieb Mark Thomas:
>> On 17/02/2020 15:07, Michael Osipov wrote:



>>> So the server tries to read those advertised 15 bytes from the client
>>> while the input stream on client side has been exhausted. The reqest
>>> times out.
>>>
>>> I don't understand why I don't get a 408 according to RFC 7231, section
>>> 6.5.7: The 408 (Request Timeout) status code indicates that the server
>>> did not receive a complete request message within the time that it was
>>>   prepared to wait...
>>>
>>> Jetty 9.4.x suffers from the same problem while HTTPd does send a
>>> request timeout.
>>>
>>> Ideas?
>>
>> 
>> If a servlet generates an error that is not handled by the error page
>> mechanism as described above, the container must ensure to send a
>> response with status 500.
>> 
>>
>> Note the "must" in the above quote.
>>
>> Even if Tomcat ignored the above requirement, I'm not sure if Tomcat
>> always has enough information about what the application is doing to
>> correctly identify when it should use a 408 rather than a 500 status
>> code.
>>
>> The simplest solution would be to handle the SocketTimeoutException in
>> the application and return a 408 when appropriate.
> 
> I don't understand that reasoning. It says "servlet", but my servlet
> does not throw any exception (expliclitly). The exception clearly
> happens inside the container.

An I/O exception is thrown from the doPut() method. Section 19.9.2
applies. The exact source of the exception is not relevant.

> The exception description says "Signals
> that a timeout has occurred on a socket read or accept." It seems pretty
> obvious to me that after we have received the request line it is a
> SC_REQUEST_TIMEOUT.

I agree. In this case. And the main reason I agree is that I can read
the client code and understand what is going on. The container does not
have the ability to do that.

> I also don't understand why I should handle in application code
> non-application errors from the container? It is a perfectly normal
> situation that clients don't deliver data in time. Especially the
> exception name says: "ClientAbortException".

Because the Servlet specification says you have to.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Enhancement: New option 'persistAuthentication' for session manager