Re: JASPIC Implementation pointers

[Mark Thomas]

On 03/07/2015 07:37, Fjodor Vershinin wrote:
> Hi!
> Unfortunately, commit rearrangement requires some more effort from me, so I
> haven't finished it yesterday.
> I need some more time to fix checkstyle errors and so on.

OK.

>> We can change the way users have to configure it. For example, we could
>> say they have to use programmatic configuration via the standard JASPIC
>> interfaces if they want to use non-default settings.
> 
> 
> I see your point. The best option in my opinion is is to pass this options
> through LoginConfig/Context in ContextConfig.
> We can figure out how to set these options in a programmatic way and then
> refresh the context provider in order to reinitialize authenitcation
> modules.

Why do you say reinitialize? I'd expect a new instance of the module to
be created when the web application starts and that instance to be used
until it stops (requiring a stop/start to update config happens a lot in
Tomcat - not that much configuration is configurable dynamically).

Mark


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

Re: JASPIC Implementation pointers

[Fjodor Vershinin]

2015-07-03 15:31 GMT+03:00 Mark Thomas :

> On 03/07/2015 07:37, Fjodor Vershinin wrote:
> > Hi!
> > Unfortunately, commit rearrangement requires some more effort from me,
> so I
> > haven't finished it yesterday.
> > I need some more time to fix checkstyle errors and so on.
>
> OK.

I have prepared patchset in
https://github.com/fjodorver/tomcat/commits/feature/form_auth branch, some
commits are squashed. However I think it's reasonable to save refactoring
commits in order to have possibility for tracing code changes and discuss
about them.


> >> We can change the way users have to configure it. For example, we could
> >> say they have to use programmatic configuration via the standard JASPIC
> >> interfaces if they want to use non-default settings.
> >
> >
> > I see your point. The best option in my opinion is is to pass this
> options
> > through LoginConfig/Context in ContextConfig.
> > We can figure out how to set these options in a programmatic way and then
> > refresh the context provider in order to reinitialize authenitcation
> > modules.
>
> Why do you say reinitialize? I'd expect a new instance of the module to
> be created when the web application starts and that instance to be used
> until it stops (requiring a stop/start to update config happens a lot in
> Tomcat - not that much configuration is configurable dynamically).

Here is the thing: currently we initialize our embedded provider on
application startup, if application has login-config in web.xml.
So, we need to invent some mechanism to detect, if person wants to use
custom provider or embedded one.
I have an idea, that login-config is for embedded provider only, so, in
case users want to use their custom provider, and do not want to use
embedded one, they should avoid using login-config in application config.
Another option is unregister Tomcat's default provider, and register custom
one.

Thanks,
Fjodor

Re: svn commit: r1688911 - /tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java

[Konstantin Kolinko]

2015-07-03 0:07 GMT+03:00  :
> Author: markt
> Date: Thu Jul  2 21:07:18 2015
> New Revision: 1688911
>
> URL: http://svn.apache.org/r1688911
> Log: (empty)

Log message =?
This looks like a followup to http://svn.apache.org/r1688909

Removing "ka = null;" line has no effect, as "ka" variable is not used
below. OK with it.

Removing "socket = null;" line has an effect on
catch(OutOfMemoryError) clause. An unlikely use case, though.

If we keep the "socket = null;" line , it can be moved into the close() method.
Note that it will be "this.socket = null;" there, as socket argument
of the close() method shadows socket field of the class.

> -if (socket.getPoller().cancelledKey(key, SocketStatus.ERROR, 
> false) != null) {
> +if (socket.getPoller().cancelledKey(key, socketStatus, 
> false) != null) {

OK.
The above was a copy-paste fix from extracting common code into as
method in r1688909.
The error was that socketStatus argument was not used.

Best regards,
Konstantin Kolinko

> Modified:
> tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
>
> Modified: 
> tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
> URL: 
> http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java?rev=1688911&r1=1688910&r2=1688911&view=diff
> ==
> --- tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java 
> (original)
> +++ tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java Thu 
> Jul  2 21:07:18 2015
> @@ -1756,20 +1756,17 @@ public class NioEndpoint extends Abstrac
>  // Close socket and pool
>  try {
>  close(ka, socket, key, SocketStatus.ERROR);
> -socket = null;
> -ka = null;
>  } catch ( Exception x ) {
>  log.error("",x);
>  }
>  }
>  } else if (handshake == -1 ) {
>  close(ka, socket, key, SocketStatus.DISCONNECT);
> -ka = null;
>  } else {
>  ka.getPoller().add(socket, handshake);
>  }
> -}catch(CancelledKeyException cx) {
> -socket.getPoller().cancelledKey(key,null,false);
> +} catch (CancelledKeyException cx) {
> +socket.getPoller().cancelledKey(key, null, false);
>  } catch (OutOfMemoryError oom) {
>  try {
>  oomParachuteData = null;
> @@ -1809,7 +1806,7 @@ public class NioEndpoint extends Abstrac
>  if (ka != null) {
>  ka.setComet(false);
>  }
> -if (socket.getPoller().cancelledKey(key, SocketStatus.ERROR, 
> false) != null) {
> +if (socket.getPoller().cancelledKey(key, socketStatus, 
> false) != null) {
>  // SocketWrapper (attachment) was removed from the
>  // key - recycle both. This can only happen once
>  // per attempted closure so it is used to determine
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

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

Re: JASPIC Implementation pointers

[Mark Thomas]

On 03/07/2015 13:56, Fjodor Vershinin wrote:
> 2015-07-03 15:31 GMT+03:00 Mark Thomas :
> 
>> On 03/07/2015 07:37, Fjodor Vershinin wrote:
>>> Hi!
>>> Unfortunately, commit rearrangement requires some more effort from me,
>> so I
>>> haven't finished it yesterday.
>>> I need some more time to fix checkstyle errors and so on.
>>
>> OK.
> 
> I have prepared patchset in
> https://github.com/fjodorver/tomcat/commits/feature/form_auth branch, some
> commits are squashed. However I think it's reasonable to save refactoring
> commits in order to have possibility for tracing code changes and discuss
> about them.

OK. I'll hopefully start reviewing and merging those this afternoon.

 We can change the way users have to configure it. For example, we could
 say they have to use programmatic configuration via the standard JASPIC
 interfaces if they want to use non-default settings.
>>>
>>>
>>> I see your point. The best option in my opinion is is to pass this
>> options
>>> through LoginConfig/Context in ContextConfig.
>>> We can figure out how to set these options in a programmatic way and then
>>> refresh the context provider in order to reinitialize authenitcation
>>> modules.
>>
>> Why do you say reinitialize? I'd expect a new instance of the module to
>> be created when the web application starts and that instance to be used
>> until it stops (requiring a stop/start to update config happens a lot in
>> Tomcat - not that much configuration is configurable dynamically).
> 
> Here is the thing: currently we initialize our embedded provider on
> application startup, if application has login-config in web.xml.

Not quite.

If the user has defined an authenticator Valve in context.xml or
server.xml then that is used and any login-config in web.xml is ignored.

> So, we need to invent some mechanism to detect, if person wants to use
> custom provider or embedded one.

Or, as currently, simply define an order of preference.

> I have an idea, that login-config is for embedded provider only, so, in
> case users want to use their custom provider, and do not want to use
> embedded one, they should avoid using login-config in application config.
> Another option is unregister Tomcat's default provider, and register custom
> one.

Another option would be to define a jaspic element for server.xml /
context.xml that is nested in a Context and if present takes precedence
for JASPIC config. For that to work modules would have to:
- have zero arg constructors
- be fully configurable via setters
- use simple types for their property setters

How feasible is that?

Mark


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

Re: JASPIC Implementation pointers

[Fjodor Vershinin]

>
>
> Another option would be to define a jaspic element for server.xml /
> context.xml that is nested in a Context and if present takes precedence
> for JASPIC config. For that to work modules would have to:
> - have zero arg constructors
> - be fully configurable via setters
> - use simple types for their property setters
>
> How feasible is that?


I think it sounds even better, however I would like to allow security
configuration only on the provider basis.
Provider can be initalized with settings HashMap, which can be passed
directly to modules on initialization.
And then, modules can set own settings using provided information.

-- 
Thanks,
Fjodor

Early Access builds for JDK 8u60 b21 and JDK 9 b70 are available on java.net

[Rory O'Donnell]

Hi Mark/Mladen,

Early Access build for JDK 8u60 b21  
is available on java.net, summary of changes are listed here. 

As we enter the later phases of development for JDK 8u60, please log any 
show stoppers as soon as possible.


Early Access build for JDK 9 b70  is 
available on java.net, summary of  changes are listed here 
.


The JDK 9 schedule of record is available on the JDK 9 Project page: 
http://openjdk.java.net/projects/jdk9


At https://wiki.openjdk.java.net/display/Adoption/JDK+9+Outreach you can 
find a (preliminary) list of other
changes that might affect your project's code in JDK 9, and other things 
to consider when testing with JDK 9.
I'd be curious to know if there is anything on that list you'd consider 
to have an effect on your project.


Please keep in mind that as JEPs and others changes are integrated into 
(or out of) JDK 9, the list will change

over time.

Rgds,Rory

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

Re: JASPIC Implementation pointers

[Fjodor Vershinin]

I am working on polishing FORM authentication module code. I will continue
with that this evening.
JASPIC modules configuration looks more like architectural stuff, so we
need to make some decisions how to proceed forward. I think it can be task
for next week together SPNEGO authentication module.

Thanks,
Fjodor

2015-07-03 17:16 GMT+03:00 Fjodor Vershinin :

>
>> Another option would be to define a jaspic element for server.xml /
>> context.xml that is nested in a Context and if present takes precedence
>> for JASPIC config. For that to work modules would have to:
>> - have zero arg constructors
>> - be fully configurable via setters
>> - use simple types for their property setters
>>
>> How feasible is that?
>
>
> I think it sounds even better, however I would like to allow security
> configuration only on the provider basis.
> Provider can be initalized with settings HashMap, which can be passed
> directly to modules on initialization.
> And then, modules can set own settings using provided information.
>
> --
> Thanks,
> Fjodor
>



-- 
Thanks,
Fjodor

svn commit: r1689026 - in /tomcat/trunk/test/org/apache/catalina/authenticator: ResponseDescriptor.java TestJaspicBasicAuthenticator.java

[markt]

Author: markt
Date: Fri Jul  3 14:47:12 2015
New Revision: 1689026

URL: http://svn.apache.org/r1689026
Log:
Implemented integration test for JASPIC BASIC authentication
Patch by fjodorver

Added:
tomcat/trunk/test/org/apache/catalina/authenticator/ResponseDescriptor.java 
  (with props)

tomcat/trunk/test/org/apache/catalina/authenticator/TestJaspicBasicAuthenticator.java
   (with props)

Added: 
tomcat/trunk/test/org/apache/catalina/authenticator/ResponseDescriptor.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/authenticator/ResponseDescriptor.java?rev=1689026&view=auto
==
--- tomcat/trunk/test/org/apache/catalina/authenticator/ResponseDescriptor.java 
(added)
+++ tomcat/trunk/test/org/apache/catalina/authenticator/ResponseDescriptor.java 
Fri Jul  3 14:47:12 2015
@@ -0,0 +1,59 @@
+/*
+ *  Licensed to the Apache Software Foundation (ASF) under one or more
+ *  contributor license agreements.  See the NOTICE file distributed with
+ *  this work for additional information regarding copyright ownership.
+ *  The ASF licenses this file to You under the Apache License, Version 2.0
+ *  (the "License"); you may not use this file except in compliance with
+ *  the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ *  Unless required by applicable law or agreed to in writing, software
+ *  distributed under the License is distributed on an "AS IS" BASIS,
+ *  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ *  See the License for the specific language governing permissions and
+ *  limitations under the License.
+ */
+package org.apache.catalina.authenticator;
+
+import java.util.List;
+import java.util.Map;
+
+/**
+ * This class incorporates test response data
+ */
+class ResponseDescriptor {
+private Map> headers;
+private String body;
+private int responseCode;
+
+
+public Map> getHeaders() {
+return headers;
+}
+
+
+public void setHeaders(Map> headers) {
+this.headers = headers;
+}
+
+
+public String getBody() {
+return body;
+}
+
+
+public void setBody(String body) {
+this.body = body;
+}
+
+
+public int getResponseCode() {
+return responseCode;
+}
+
+
+public void setResponseCode(int responseCode) {
+this.responseCode = responseCode;
+}
+}
\ No newline at end of file

Propchange: 
tomcat/trunk/test/org/apache/catalina/authenticator/ResponseDescriptor.java
--
svn:eol-style = native

Added: 
tomcat/trunk/test/org/apache/catalina/authenticator/TestJaspicBasicAuthenticator.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/authenticator/TestJaspicBasicAuthenticator.java?rev=1689026&view=auto
==
--- 
tomcat/trunk/test/org/apache/catalina/authenticator/TestJaspicBasicAuthenticator.java
 (added)
+++ 
tomcat/trunk/test/org/apache/catalina/authenticator/TestJaspicBasicAuthenticator.java
 Fri Jul  3 14:47:12 2015
@@ -0,0 +1,211 @@
+/*
+ *  Licensed to the Apache Software Foundation (ASF) under one or more
+ *  contributor license agreements.  See the NOTICE file distributed with
+ *  this work for additional information regarding copyright ownership.
+ *  The ASF licenses this file to You under the Apache License, Version 2.0
+ *  (the "License"); you may not use this file except in compliance with
+ *  the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ *  Unless required by applicable law or agreed to in writing, software
+ *  distributed under the License is distributed on an "AS IS" BASIS,
+ *  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ *  See the License for the specific language governing permissions and
+ *  limitations under the License.
+ */
+package org.apache.catalina.authenticator;
+
+import java.io.IOException;
+import java.text.MessageFormat;
+import java.util.ArrayList;
+import java.util.Collection;
+import java.util.HashMap;
+import java.util.List;
+import java.util.Map;
+
+import javax.security.auth.message.config.AuthConfigFactory;
+
+import org.hamcrest.CoreMatchers;
+
+import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.assertNotNull;
+import static org.junit.Assert.assertThat;
+
+import org.junit.Test;
+
+import org.apache.catalina.Context;
+import org.apache.catalina.authenticator.jaspic.JaspicAuthenticator;
+import 
org.apache.catalina.authenticator.jaspic.provider.TomcatAuthConfigProvider;
+import org.apache.catalina.connector.Request;
+import org.apache.catalina.startup.TesterMapRealm;
+import org.apache.catalina.startup.TesterServlet;
+import org.apache.catalina.startup.Tomcat;
+import or

svn commit: r1689034 - /tomcat/trunk/java/org/apache/catalina/authenticator/jaspic/provider/modules/TomcatAuthModule.java

[markt]

Author: markt
Date: Fri Jul  3 14:59:01 2015
New Revision: 1689034

URL: http://svn.apache.org/r1689034
Log:
Fix NPE on empty realm name 
Patch by fjodorver

Modified:

tomcat/trunk/java/org/apache/catalina/authenticator/jaspic/provider/modules/TomcatAuthModule.java

Modified: 
tomcat/trunk/java/org/apache/catalina/authenticator/jaspic/provider/modules/TomcatAuthModule.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/authenticator/jaspic/provider/modules/TomcatAuthModule.java?rev=1689034&r1=1689033&r2=1689034&view=diff
==
--- 
tomcat/trunk/java/org/apache/catalina/authenticator/jaspic/provider/modules/TomcatAuthModule.java
 (original)
+++ 
tomcat/trunk/java/org/apache/catalina/authenticator/jaspic/provider/modules/TomcatAuthModule.java
 Fri Jul  3 14:59:01 2015
@@ -66,7 +66,7 @@ public abstract class TomcatAuthModule i
 
 
 public String getRealmName() {
-return Optional.of(realmName).orElse(DEFAULT_REALM_NAME);
+return Optional.ofNullable(realmName).orElse(DEFAULT_REALM_NAME);
 }
 
 



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

Re: JASPIC Implementation pointers

[Mark Thomas]

On 03/07/2015 15:42, Fjodor Vershinin wrote:
> I am working on polishing FORM authentication module code. I will continue
> with that this evening.

OK. I'm commenting on commits as I apply them. Some of them have
suggestions for further improvements. These improvements don't need to
be implemented now (if you have time then great). As a minimum there
needs to be a TODO comment added to the right place(s) in the code so
you can come back to them later.


> JASPIC modules configuration looks more like architectural stuff, so we
> need to make some decisions how to proceed forward.

What decisions? If you can define these before the weekend that gives
folks a few days to think about it before you need answers.

> I think it can be task
> for next week together SPNEGO authentication module.

SPNEGO is likely to be tricky since setting up a test environment needs
server machines and some Windows Server licenses. I have a set of VMs I
use for testing SPNEGO. It probably makes sense if you port it and I
test it.

Mark

> 
> Thanks,
> Fjodor
> 
> 2015-07-03 17:16 GMT+03:00 Fjodor Vershinin :
> 
>>
>>> Another option would be to define a jaspic element for server.xml /
>>> context.xml that is nested in a Context and if present takes precedence
>>> for JASPIC config. For that to work modules would have to:
>>> - have zero arg constructors
>>> - be fully configurable via setters
>>> - use simple types for their property setters
>>>
>>> How feasible is that?
>>
>>
>> I think it sounds even better, however I would like to allow security
>> configuration only on the provider basis.
>> Provider can be initalized with settings HashMap, which can be passed
>> directly to modules on initialization.
>> And then, modules can set own settings using provided information.
>>
>> --
>> Thanks,
>> Fjodor
>>
> 
> 
> 


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

[Bug 58095] Empty

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58095

--- Comment #3 from Christopher Schultz  ---
I'm not sure this is a Tomcat issue, but I'm not sure exactly how Tomcat does
its XML parsing, etc. I know that I've seen this problem with other
XML-oriented HTML-handling software as well.

A specific case in point: Apache Cocoon will take a  pair in
an XSLT and generate  in the output. We have to use the same tricks
like boo! in order to prevent the
XML serializer from coalescing the tags together.

The problem is likely to be that the XML serializer doesn't realize that there
are certain HTML tags that cannot be self-closing (and  is the only one
I know of of-hand). As far as XML is concerned,