I'm building Geronimo trunk locally without any hacks, so I should have the
latest stuff. There's of course a chance there's something wrong with my
local build, though I've not had such issues before.
I'll try the testsuite as suggested and debugging the sample app a bit
further. Due to the Jetty API changes I can't run the revisions before you
fixed this against the current Jetty trunk, but I've checked that the sample
app works with Geronimo r799958 and Jetty r614. Will do some more tests
tomorrow and let you know what I find.
Thanks for helping out!
Trygve
On Tue, Aug 4, 2009 at 10:36 PM, David Jencks <david_jen...@yahoo.com>wrote:
>
> On Aug 4, 2009, at 10:38 AM, Trygve Hardersen wrote:
>
> Hi
>
> Is it possible that these changes broke run-as security for Jetty7
> servlets? At least something changed between r799958 and r800712 that causes
> our run-as servlets to run as UNAUTHENTICATED with the latest Geronimo
> 2.2-SNAPSHOT.
>
> I provided a sample application in relation to GERONIMO-4756 that
> demonstrates run-as security for servlets talking to EJBs. AFAICT this now
> behaves as prior to r797291 again; the servlets are not authenticated.
>
> I've looked through the various run-as and security discussions that have
> been going on lately, but I can't see that our approach has been invalidated
> by any of the changes.
>
>
> I didn't try re-running your sample app and havent had time to turn it into
> a testsuite app, but the existing testsuite run-as test still appears to
> work fine. It checks that run-as roles on servlets and ejbs are correctly
> used during servlet dispatch and servlet calls to ejbs. On the other hand
> I'm not sure when geronimo snapshots are pushed, so I may have more recent
> code.
>
> Can you check against trunk (if you haven't already) and see if you can
> narrow the problem down a little further?
>
> BTW to run the testuite stuff individually you can start a g. server
> somewhere and in testsuite/enterprise-testsuite/sec-tests add the following
> profile to the pom in sec-ear/pom.xml:
>
> <profiles>
> <profile>
> <!-- use to start up selenium when running a single test
> against an already-started server -->
> <id>standalone</id>
> <build>
> <plugins>
> <plugin>
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>selenium-maven-plugin</artifactId>
> <inherited>false</inherited>
> <executions>
> <execution>
> <id>start</id>
> <phase>pre-integration-test</phase>
> <goals>
> <goal>start-server</goal>
> </goals>
> <configuration>
> <logOutput>true</logOutput>
> <background>true</background>
> <systemProperties>
> <property>
> <name>browser</name>
> <value>${browser}</value>
> </property>
> </systemProperties>
> </configuration>
> </execution>
> <execution>
> <id>stop</id>
> <phase>post-integration-test</phase>
> <goals>
> <goal>stop-server</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
>
> </plugins>
> </build>
> </profile>
> </profiles>
>
>
> and run mvn clean install -Pstandalone
>
>
> thanks
> david jencks
>
>
> Any help or insight to this is greatly appreciated.
>
> Thanks!
>
> Trygve Hardersen
> Jotta AS
>
>
> On Mon, Aug 3, 2009 at 6:30 PM, David Jencks <david_jen...@yahoo.com>wrote:
>
>> Greg changed some things around here over the weekend. I'm looking into
>> this. There's some chance this will fix the problems Ivan mentioned with
>> dispatch versus redirect to the login page.
>>
>> thanks
>> david jencks
>>
>>
>> On Aug 3, 2009, at 8:25 AM, Jason Warner wrote:
>>
>> I'm seeing some compilation failures on trunk[1]. Does anyone else get
>>> the same error? I'm building using java version 1.5.0 update 19 on a mac.
>>> The TCK builds are seeing the same failures as well, and they run using the
>>> same java version but on linux.
>>>
>>> [1]
>>> [INFO]
>>> ------------------------------------------------------------------------
>>> [ERROR] BUILD FAILURE
>>> [INFO]
>>> ------------------------------------------------------------------------
>>> [INFO] Compilation failure
>>>
>>> /Users/jason/trunk/plugins/jetty7/geronimo-jetty7/src/main/java/org/apache/geronimo/jetty7/security/JettySecurityHandlerFactory.java:[46,49]
>>> cannot find symbol
>>> symbol : class SessionCachingAuthenticator
>>> location: package org.eclipse.jetty.security.authentication
>>>
>>> /Users/jason/trunk/plugins/jetty7/geronimo-jetty7/src/main/java/org/apache/geronimo/jetty7/connector/JettyConnector.java:[90,23]
>>> [deprecation] getHeaderBufferSize() in org.eclipse.jetty.http.HttpBuffers
>>> has been deprecated
>>>
>>> /Users/jason/trunk/plugins/jetty7/geronimo-jetty7/src/main/java/org/apache/geronimo/jetty7/connector/JettyConnector.java:[93,16]
>>> [deprecation] setHeaderBufferSize(int) in org.eclipse.jetty.http.HttpBuffers
>>> has been deprecated
>>>
>>> /Users/jason/trunk/plugins/jetty7/geronimo-jetty7/src/main/java/org/apache/geronimo/jetty7/security/auth/JAASLoginService.java:[40,7]
>>> org.apache.geronimo.jetty7.security.auth.JAASLoginService is not abstract
>>> and does not override abstract method
>>> validate(org.eclipse.jetty.server.UserIdentity) in
>>> org.eclipse.jetty.security.LoginService
>>>
>>> /Users/jason/trunk/plugins/jetty7/geronimo-jetty7/src/main/java/org/apache/geronimo/jetty7/security/JettySecurityHandlerFactory.java:[102,32]
>>> cannot find symbol
>>> symbol : class SessionCachingAuthenticator
>>> location: class
>>> org.apache.geronimo.jetty7.security.JettySecurityHandlerFactory
>>>
>>> /Users/jason/trunk/plugins/jetty7/geronimo-jetty7/src/main/java/org/apache/geronimo/jetty7/security/JettySecurityHandlerFactory.java:[102,60]
>>> cannot find symbol
>>> symbol : constructor
>>> FormAuthenticator(java.lang.String,java.lang.String)
>>> location: class
>>> org.eclipse.jetty.security.authentication.FormAuthenticator
>>>
>>>
>>> ~Jason Warner
>>>
>>
>
>
