[jetty-discuss] signed jar certificates problems

[Eric White <eric.white@io...>]

I'm trying to deploy some WARs of open source wiki projects into both
Jetty 5.1.10 and 5.1.11.  I've also tried those Jetty versions with JDK
versions 1.4.2_08 and 1.5.0_07.

Each of the 3 different WARs I'm trying to deploy generates an error, in
the jetty log, something akin to:

<no certificates>))=java.security.Permissions

for different jar files packaged within the WAR or even the
WEB-INF/classes directory in some cases. The syntax of the message
changes a bit between the two JDK versions, but the results are the same.

Since I'm seeing this same behavior on 3 different WAR deployments, I
must have something mis-configured in my versions of Jetty, but can't
figure it out.  It appears there is some jar signing problem but I've
noticed this error on log4j.jar in a couple of the WAR distro's as well.

Any ideas/help/pointers would be greatly appreciated.

thanks

Re: [jetty-discuss] JAAS behavior

[Jan Bartel <janb@mo...>]

Jean-Baptiste,

Here's the diffs for jetty6. It should be quite easy to see what to do
in jetty5. The main change was to remove the map of authenticated users.

cheers
Jan

Jean-Baptiste REURE wrote:
> Hi Jan,
> 
> I was away for a while and just had your email last week.
> So first of all, thanks for fixing that problem for us.
> Secondly, we actually use an earlier version of Jetty (5.1.10 - 5 
> January 2005) in production so we cannot afford to switch to Jetty 6 
> just yet. Could you actually point to me what the change(s) was/were and 
> we'll give it a go here.
> 
> Thanks,
> 
> JB.
> 
> Jan Bartel wrote:
> 
>>Jean-Baptiste,
>>
>>Well *I* don't think it was consistent. Also, I think it should be
>>perfectly reasonable to have 2+ independent simultaneous logins.
>>
>>So, I've modified Jetty to make this possible. It's checked in to
>>svn head now.
>>
>>Try it out and let me know how it goes.
>>
>>Thanks for bringing this to my attention.
>>
>>cheers
>>Jan
>>  
> 
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[jetty-discuss] mod_jk setup with apache

[Thinh Nguyen <thainguy99@ho...>]

Hi all,

I've been trying to search through Google and mailing lists etc... I 
couldn't find any information that can help me setup apache to serve the 
static contents while jetty serve *.jsp and servlet.

I've done the followings:
1. I downloaded the mod_jk-apache-2.0.58.so and moved it to 
apache_install_dir/modules
2. Modified the httpd.conf to have LoadModule jk_module 
modules/mod_jk-apache-2.0.58.so (I tried jk2_module and apache can't even 
start successfully)

3. I've checked the jetty.xml and it contains the following information 
about mod_jk
  <Call name="addListener">
    <Arg>
      <New class="org.mortbay.http.ajp.AJP13Listener">
        <Set name="PoolName">ajp</Set>
        <Set name="Port">8009</Set>
	<Set name="Host">localhost</Set>
        <Set name="MinThreads">3</Set>
        <Set name="MaxThreads">20</Set>
        <Set name="MaxIdleTimeMs">0</Set>
        <Set name="confidentialPort">443</Set>
      </New>
    </Arg>
  </Call>

And I am stuck after this. Do I need to create a worker.properties? and add 
that to the httpd.conf somehow?

Could anyone please help me solving this issue?

Thanks & regards,
Tim

_________________________________________________________________
New year, new job – there's more than 100,00 jobs at SEEK 
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau&_t=752315885&_r=Jan05_tagline&_m=EXT

Re: [jetty-discuss] JAAS behavior

[Jean-Baptiste REURE <jbreure@al...>]

Hi Jan,

I was away for a while and just had your email last week.
So first of all, thanks for fixing that problem for us.
Secondly, we actually use an earlier version of Jetty (5.1.10 - 5 
January 2005) in production so we cannot afford to switch to Jetty 6 
just yet. Could you actually point to me what the change(s) was/were and 
we'll give it a go here.

Thanks,

JB.

Jan Bartel wrote:
> Jean-Baptiste,
>
> Well *I* don't think it was consistent. Also, I think it should be
> perfectly reasonable to have 2+ independent simultaneous logins.
>
> So, I've modified Jetty to make this possible. It's checked in to
> svn head now.
>
> Try it out and let me know how it goes.
>
> Thanks for bringing this to my attention.
>
> cheers
> Jan
>   

Re: [jetty-discuss] API or other (JAAS?) recommended 'masquerade' login method

[Jan Bartel <janb@mo...>]

Ken,

Thanks for that! There was a bug in the way we were hiding jetty impl
classes from webapps that we've now fixed.

The bad news for you is that you won't be doing any casting of the
request inside a Filter or a Servlet ;-)

I think you'll have to look at subclassing org.mortbay.jetty.security.SecurityHandler
to get access to the interfaces you want.

regards
Jan


Ken Johanon wrote:
> Jan Bartel wrote:
> 
>>On the road from OSCON still, so just time for a quick interjection here - 
>>
>>
>>Are you saying you _have_ cast to org.mortbay.jetty.Request or you
>>think you _could_ do that? The webapp classloader should prevent
>>visibility of all org.mortbay classes from within a webapp, but allow
>>a couple of specific packages, such as org.mortbay.naming and org.mortbay.util.
>>Also, if you actually have done it, can you tell me if it was from within
>>a standard servlet or a JSP page?
>>
>>thanks
>>Jan
>>
>>
> 
> 
> Jan, I've only verified that I can do the following, from the 
> /test/snoop.jsp page...
> 
> Request r = (Request)request;
> out.println(request.getClass());
> 
> It indeed prints the full class name, and throws no ClassCast or other 
> exceptions.
> 
> I haven't yet tried calling any members in that class, though, :
> 
> Request r = (Request)request;
> out.println(request.getClass());
> r.setUserPrincipal(new java.security.Identity("ken"));
> 
> did not compile or perhaps exec (not verbose on the response as to 
> compile time errors or runtime exceptions, and I'm still learning how to 
> turn that on or log it)
> 
> But:
> 
> Request r = (Request)request;
> out.println(request.getClass());
> r.setTimeStamp(1l);
> 
> did compile+execute.
> 
> Using jetty-6.0.0beta17.
> 
> Ken
> 
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [jetty-discuss] API or other (JAAS?) recommended 'masquerade' login method

[Ken Johanon <jetty-user@ke...>]

Jan Bartel wrote:
> On the road from OSCON still, so just time for a quick interjection here - 
> 
> 
> Are you saying you _have_ cast to org.mortbay.jetty.Request or you
> think you _could_ do that? The webapp classloader should prevent
> visibility of all org.mortbay classes from within a webapp, but allow
> a couple of specific packages, such as org.mortbay.naming and org.mortbay.util.
> Also, if you actually have done it, can you tell me if it was from within
> a standard servlet or a JSP page?
> 
> thanks
> Jan
> 
> 

Jan, I've only verified that I can do the following, from the 
/test/snoop.jsp page...

Request r = (Request)request;
out.println(request.getClass());

It indeed prints the full class name, and throws no ClassCast or other 
exceptions.

I haven't yet tried calling any members in that class, though, :

Request r = (Request)request;
out.println(request.getClass());
r.setUserPrincipal(new java.security.Identity("ken"));

did not compile or perhaps exec (not verbose on the response as to 
compile time errors or runtime exceptions, and I'm still learning how to 
turn that on or log it)

But:

Request r = (Request)request;
out.println(request.getClass());
r.setTimeStamp(1l);

did compile+execute.

Using jetty-6.0.0beta17.

Ken

Re: [jetty-discuss] API or other (JAAS?) recommended 'masquerade' login method

[Jan Bartel <janb@mo...>]

On the road from OSCON still, so just time for a quick interjection here - 


Are you saying you _have_ cast to org.mortbay.jetty.Request or you
think you _could_ do that? The webapp classloader should prevent
visibility of all org.mortbay classes from within a webapp, but allow
a couple of specific packages, such as org.mortbay.naming and org.mortbay.util.
Also, if you actually have done it, can you tell me if it was from within
a standard servlet or a JSP page?

thanks
Jan


Ken Johanon wrote:
> Tim Vernum wrote:
> 
>>Alternatively, if you're willing to be non portable, then the  
>>HttpServletRequest in Jetty 6 is implemented by the "Request" class.
>>This class has a "setUserPrincipal" method already. However you can't  
>>always cast the request directly, because it might be a wrapper, so  
>>if you want
>>to take that approach you'll have to use this code:
>>             Request base_request = (request instanceof Request) ?  
>>(Request)request:HttpConnection.getCurrentConnection().getRequest();
>>
>>
>>  
> 
> Tim, thank you! Yes, I think that (org.mortbay.jetty.Request) is the API 
> that I'm looking for. Being non-portable is fine, and it seems to be the 
> only way to have all the control at the levels I mentioned. If there 
> were an interface in the servlet spec (someday) that allowed 
> applications to authenticate a user to the server, that would be the way 
> to go of course, but for now I think I'll need to use this approach.
> 
> Insofar as your other idea to use a filter, I dont think I could use 
> that method... the user needs to be 'truly' authenticated on the server, 
> not just in a filter context... I think my choice of the word 
> 'masquerade' was bad in that sense.
> 
> I dont mean to shoot myself in the foot, but I do notice that from 
> within a JSP (etc) it truly is just a matter of casting request to a 
> org.mortbay.jetty.Request.... this does what I need, and yet seems like 
> a security issue since it allows ordinary webapps to have more controls 
> that one would expect.. Also for having the classloader access.
> 
> So, is there any plan to eventually wrap all these into a facade class 
> that only implements the interfaces, and calls into the 
> org.mortbay.jetty.*'s? And protected classloader? Or perhaps if there 
> already is one that users can opt to use and this default behavior wont 
> change or will be selectable in a config, then I can feel more secure in 
> relying on this to achieve my masquerade ability.
> 
> Or, if (like some other servers) there was single endorsed server API / 
> class that would insulate us from changes to this..
> 
> Thanks again, and sorry for so many questions. I'm just getting to know 
> Jetty.
> 
> ken
> 
> 
> 
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [jetty-discuss] API or other (JAAS?) recommended 'masquerade' loginmethod

[Ken Johanon <jetty-user@ke...>]

Chris Haynes wrote:
>  Ken,
> 
> I don't know if JAAS can do any of this directly.
> 
> My personal preference is to wade in and develop just what I need, anyway.
> I'm pretty sure what you want is do-able in Jetty, but using a Filter rather 
> than Servlet APIs.
> 
> I would start by taking an existing Security Filter and modifying it. I've a 
> feeling that, given the 3rd party API in a nice, clean form (i.e. offering 
> exactly the APIs which are architecturally needed) the changes would only 
> involve a few lines of code.
> 
> There is one fundamental restriction to what you plan that you should be aware 
> of. When using SSL client authentication, the first certificate-related step in 
> the TLS protocol is for the server to declare which issuing authorities it will 
> recognize. Any X509 certificate offered in response must have descended from one 
> of these issuers. So it is not the case that your clients can offer _any_ 
> certificate and have its DN inspected at the server; certificates from 
> unexpected issuers cannot even get as far as the server.
> 
> If that restriction is OK, then, architecturally, you can do what you want with 
> DNs etc. All the information on the client certificate is made available by 
> Jetty (I don't believe there is a Sun-defined Filter/Servlet API for this, so 
> the access detail is 'proprietary' to Jetty). Your 3rd party API would have to 
> be prepared to receive an instance of the Sun security object representing such 
> a certificate (java.security.cert.X509Certificate).
> 
> At various times I've done with Jetty about 80% of what you want, including 
> post-TLS-handshake validation of DNs, so I'm pretty sure what you need is 
> possible.
> 
> HTH
> 
> Chris Haynes
> 


Chris, yes I agree - developing is by is definitely doing to be 
necessary. Especially for form based logins (restrictions 
j_security_check, etc), and implicit SSL logins. It seems like a 
masquerade API (i.e setUserPrinical) is the only way to go, though the 
filter may definitely have some value in that.

Your points are well taken on the certificate chain validation. Though I 
would normally allow the chain to be validated against the trust store, 
I do know that server also offer an option to allow even self signed 
certs to be accepted (i.e they wont reject the connection). This so that 
the API can use some completely custom solution to validate the certs 
(because there is not interface/spec for client cert validation at the 
server level (TrustManager interface with Servlet API)). And I know that 
the server should expose the client cert chain as a request-attribute 
(cant remember its name at the moment). I'll have to dig in and see if 
jetty supports the 'optional' and not-validated cert options, and to 
verify it exposes the client cert chain as a req attribute. I'm pretty 
confident that it does though; the reading I've done on Jetty suggests 
it is quite comprehensive.

Thank you for you suggestions, I certainly appreciate it!!

ken

Re: [jetty-discuss] API or other (JAAS?) recommended 'masquerade' login method

[Ken Johanon <jetty-user@ke...>]

Tim Vernum wrote:
> Alternatively, if you're willing to be non portable, then the  
> HttpServletRequest in Jetty 6 is implemented by the "Request" class.
> This class has a "setUserPrincipal" method already. However you can't  
> always cast the request directly, because it might be a wrapper, so  
> if you want
> to take that approach you'll have to use this code:
>              Request base_request = (request instanceof Request) ?  
> (Request)request:HttpConnection.getCurrentConnection().getRequest();
>
>
>   
Tim, thank you! Yes, I think that (org.mortbay.jetty.Request) is the API 
that I'm looking for. Being non-portable is fine, and it seems to be the 
only way to have all the control at the levels I mentioned. If there 
were an interface in the servlet spec (someday) that allowed 
applications to authenticate a user to the server, that would be the way 
to go of course, but for now I think I'll need to use this approach.

Insofar as your other idea to use a filter, I dont think I could use 
that method... the user needs to be 'truly' authenticated on the server, 
not just in a filter context... I think my choice of the word 
'masquerade' was bad in that sense.

I dont mean to shoot myself in the foot, but I do notice that from 
within a JSP (etc) it truly is just a matter of casting request to a 
org.mortbay.jetty.Request.... this does what I need, and yet seems like 
a security issue since it allows ordinary webapps to have more controls 
that one would expect.. Also for having the classloader access.

So, is there any plan to eventually wrap all these into a facade class 
that only implements the interfaces, and calls into the 
org.mortbay.jetty.*'s? And protected classloader? Or perhaps if there 
already is one that users can opt to use and this default behavior wont 
change or will be selectable in a config, then I can feel more secure in 
relying on this to achieve my masquerade ability.

Or, if (like some other servers) there was single endorsed server API / 
class that would insulate us from changes to this..

Thanks again, and sorry for so many questions. I'm just getting to know 
Jetty.

ken

Re: [jetty-discuss] Differences in Tomcat and Jetty in session id tracking

[Greg Wilkins <gregw@mo...>]

Y,

I don't understand your problem?
The ID is different to the ID previously in the handling? or from a
different browser?

ID's should be be mostly random and unpredictable,

can  you explain some more?

regards



yborov wrote:
> My current application seems to be getting the same session id whether
> the user is using MSIE and/or Mozilla Firefox or Opera, when I
> deployed it in Tomcat. However, when I deploy this in Jetty, I seemed
> to be getting different session id for MSIE and Mozilla Firefox.
> 
> -------------------------
> 
>        HttpServletRequest httpreq;        
>         try {
>             httpreq = (HttpServletRequest)request;
>         } catch (ClassCastException e) {
>             if (logger.isEnabledFor(Level.WARN)) {
>                 logger.warn("Unable to cast to HTTP request");
>             }
>             return;
>         }
>         
>         HttpSession session = httpreq.getSession(); 
>         logger.info("Session id: " + getId()); // I am getting
> different session id here when deployed in Jetty, but Tomcat give me
> the same session id.
> 
> ------------------------
> 
> Initially, I am deploying:
>    Apache-(ajp13)->Tomcat
> but I wanted to move to:
>    Apache-(apj13)->Jetty
> 
> I do want to keep the same behavior as that in Tomcat. Any help is
> much appreciated.
> 
> Y
> 
> 
> 
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [jetty-discuss] API or other (JAAS?) recommended 'masquerade' loginmethod

[Chris Haynes <chris@ha...>]

 Ken,

I don't know if JAAS can do any of this directly.

My personal preference is to wade in and develop just what I need, anyway.
I'm pretty sure what you want is do-able in Jetty, but using a Filter rather 
than Servlet APIs.

I would start by taking an existing Security Filter and modifying it. I've a 
feeling that, given the 3rd party API in a nice, clean form (i.e. offering 
exactly the APIs which are architecturally needed) the changes would only 
involve a few lines of code.

There is one fundamental restriction to what you plan that you should be aware 
of. When using SSL client authentication, the first certificate-related step in 
the TLS protocol is for the server to declare which issuing authorities it will 
recognize. Any X509 certificate offered in response must have descended from one 
of these issuers. So it is not the case that your clients can offer _any_ 
certificate and have its DN inspected at the server; certificates from 
unexpected issuers cannot even get as far as the server.

If that restriction is OK, then, architecturally, you can do what you want with 
DNs etc. All the information on the client certificate is made available by 
Jetty (I don't believe there is a Sun-defined Filter/Servlet API for this, so 
the access detail is 'proprietary' to Jetty). Your 3rd party API would have to 
be prepared to receive an instance of the Sun security object representing such 
a certificate (java.security.cert.X509Certificate).

At various times I've done with Jetty about 80% of what you want, including 
post-TLS-handshake validation of DNs, so I'm pretty sure what you need is 
possible.

HTH

Chris Haynes


"Ken Johanon" asked:


> Hello,
>
> I believe what I need to do can may only be accomplished at the API
> level; that the combination of login requirements cannot be accomplished
> using contemporary JAAS/etc methods.
>
> Effectively, I need to allow a 3rd party API to masquerade a user (join
> their session with a Principal). Even though that is not servlet
> compliant or portable.
>
> What the 3rd party API needs to support (and I am able to right now
> using another server that supports a masquerade API) is:
>
> -Login forms: the user must be able to enter any accepted unique
> identifier in the 'username' field; this can be the user's assigned
> username, OR their email address, OR a X509 DN, divers-license, etc. The
> 3rd party API performs a database or LDAP lookup using any one of those
> inputs, the returns the user's Principal id (a traditional 'username').
> If the password matches the user's database / LDAP credentials (hash,
> etc), the API then calls the server's 'masquerade' API.
>
> -X509: when SSL client authentication is enabled (in the 'optional
> mode') and the user offers a cert... the DN from the cert is validated
> against a database and other logic (OCSP, issuer's use-policies, etc),
> and if valid, the Principal name is again returned, and passed to the
> server's masquerade function for an implicit login.
>
> So the combination of all these requirements seems to require an
> API-level (non-portable) interface into the server... a "masquerade"
> function... to join a Principal to the HttpSession..
>
> Has anyone done something similar with Jetty? I'd appreciate any
> pointers into if/how one could access the server internal APIs... from
> the servlet level. Or if anyone knows that this can be done with JAAS, I
> would VERY much appreciate being corrected :-)
>
> Thanks in advance,
> ken
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> jetty-discuss mailing list
> jetty-discuss@...
> https://lists.sourceforge.net/lists/listinfo/jetty-discuss
> 

Re: [jetty-discuss] API or other (JAAS?) recommended 'masquerade' login method

[Tim Vernum <tim@ad...>]

On 28/07/2006, at 3:13 PM, Ken Johanon wrote:

> Has anyone done something similar with Jetty? I'd appreciate any
> pointers into if/how one could access the server internal APIs...

I have, though not nearly as ambitious.
The masquerading should be feasible with a Filter and a  
HttpServletRequestWrapper.

Implement a class extending HSRW, add a setUserPrincipal method, and  
the override geUsertPrincipal to return your user.
Put a filter in front to do that for the appropriate requests.

That's worked for me, but as I said, my requirements were a bit  
simpler (it was a web service with the credentials inside (some of)  
the XML messages)

Alternatively, if you're willing to be non portable, then the  
HttpServletRequest in Jetty 6 is implemented by the "Request" class.
This class has a "setUserPrincipal" method already. However you can't  
always cast the request directly, because it might be a wrapper, so  
if you want
to take that approach you'll have to use this code:
             Request base_request = (request instanceof Request) ?  
(Request)request:HttpConnection.getCurrentConnection().getRequest();

Re: [jetty-discuss] error regarding running jetty on pocketpc

[Greg Wilkins <gregw@mo...>]

Yash,

if you look at http://docs.codehaus.org/display/JETTY/J2ME+CDC
you will see some instructions on how to run Jetty on IBM J9

do not use start.jar and you will need to pick an example from embedded to
use.

regards



yash singh wrote:
> hello..
>  
> Any one plz can help me .... i am from india.....
> i am trying "jetty-6.0.0beta12"  on the WM pocketpc 2003 second edition
> and the JVM IBM' j9 and on command prompt.. i follow th command
> \j9\PPRO10\bin\j9.exe -jar \jetty\start..jar
>  
> "\jetty\start.jar" becoz the start.jar in the dir jetty and i also try
> to run from shortcut
> but at last i got these
> error.................................................... 
>  
>  
> *java.lang.NumberFormatException:
>  at java.lang.Integer.parseInt(Unknown Source)
>  at java.lang.Integer.parseInt(Unknown Source)
>  at org.mortbay.start.version.parse(Unknown Source)
>  at org.mortbay..start.version.<init>(Unknown Source)
>  at org.mortbay.start..Main.configure(Unknown Source)
>  at org.mortbay.start.Main.start(Unknown Source)
>  at org.mortbay.start.Main.main(Unknown Source)
>  at java.lang.reflect.AccessibleObject.invokeV(Unknown Source)
>  at java.lang.reflect.Nethod.invoke(Unknown Source)
>  at com.ibm.oti.vm.JarRunner.main(Unknown Source)*
> ** 
> ** 
> *Yash.....*
> 
> ------------------------------------------------------------------------
> How low will we go? Check out Yahoo! Messenger’s low PC-to-Phone call
> rates.
> <http://us.rd.yahoo.com/mail_us/taglines/postman8/*http://us.rd.yahoo.com/evt=39663/*http://voice.yahoo.com>;
> 
> 
>  <http://us.rd.yahoo.com/mail_us/taglines/postman8/*http://us.rd.yahoo.com/evt=39663/*http://voice.yahoo.com>;
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV <http://us.rd.yahoo.com/mail_us/taglines/postman8/*http://us.rd.yahoo.com/evt=39663/*http://voice.yahoo.com>;
> 
> 
>  <http://us.rd.yahoo.com/mail_us/taglines/postman8/*http://us.rd.yahoo.com/evt=39663/*http://voice.yahoo.com>;
> ------------------------------------------------------------------------
> 
> _______________________________________________
> jetty-discuss mailing list
> jetty-discuss@...
> https://lists.sourceforge.net/lists/listinfo/jetty-discuss
>  <http://us.rd.yahoo.com/mail_us/taglines/postman8/*http://us.rd.yahoo.com/evt=39663/*http://voice.yahoo.com>;

[jetty-discuss] [jira] Commented: (JETTY-93) SelectChannelConnector much to slow in windows

[Greg Wilkins (JIRA) <jira@co...>]

    [ http://jira.codehaus.org/browse/JETTY-93?page=comments#action_70684 ] 
            
Greg Wilkins commented on JETTY-93:
-----------------------------------

Yug,

as I don't have two windows  machines... this is going to take me some time to look at.
Actually... I'll see if Nik can have a crack at this.

This is probably some sort of delay in noticing that the socket is writable?

Yug, can you capture some traffic with ethereal as this may tell us where the 
delay is.

> SelectChannelConnector much to slow in windows
> ----------------------------------------------
>
>                 Key: JETTY-93
>                 URL: http://jira.codehaus.org/browse/JETTY-93
>             Project: Jetty
>          Issue Type: Bug
>          Components: HTTP
>         Environment: jetty6 SVN head from 14:15 CEST 19. July 2006
> 2 computers running winxp, connected via 100MBit/s Ethernet
>            Reporter: Yug
>         Assigned To: Greg Wilkins
>         Attachments: SlowClient.java, SlowServer.java
>
>
> SelectChannelConnector is extremely slow when client AND server run windows. Serving the same ~14MB jar file takes ~88 seconds (163 kB/s) using SelectChannelConnector and ~1 second (11,8 MB/s) using SocketConnector. 
> When the client uses a smaller buffer than 32kB (see client example) , the download becomes a bit faster (up to 460 kB/s).
> (unfortunately, javaws 1.5 uses 32kB).
> When the server runs on freebsd and the client on windows, I get about 8-9 MB/s using the SelectChannelConnector. 
> I will attach the following:
> - test server which serves the current directory using SelectChannelConnector on port 18080 and SocketConnector on port 18081
> - test client which connects to the server on both ports and measures time and speed
> - a big jarfile which is served
> To reproduce:
> - Insert server hostname in SlowClient.java
> - compile client and server
> - Put SlowServer.class, big.jar and jetty libraries on one windows box and SlowClient.class on another windows box, both being connected via 100MBit ethernet.
> - run server and client

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Re: [jetty-discuss] Maven plugin with SSL

[David Yu <dyu@ex...>]

Hi Richard,

You can create a keystore from scratch by doing the following:
1. cd to your JAVA_HOME\bin directory using commandline.
2. run this line:
keytool -genkey -alias jetty6 -keyalg RSA -keystore 
E:\path\to\your\samplekeystore.keystore

And insert this insdie the <connectors> element

              <connector 
implementation="org.mortbay.jetty.security.SslSocketConnector">
              <port>8443</port>
              <maxIdleTime>60000</maxIdleTime>
              <keystore>e:/path/to/your/samplekeystore.keystore</keystore>
              <password>your keystore password</password>  // this will 
be prompted first (keystore password) after you enter the command above 
(keytool)
              <keyPassword>your keypassword</keyPassword>  // this will 
be prompted last (key password) after you enter the command above (keytool)
            </connector>

Hope this helps,
David

[jetty-discuss] [jira] Assigned: (JETTY-93) SelectChannelConnector much to slow in windows

[Greg Wilkins (JIRA) <jira@co...>]

     [ http://jira.codehaus.org/browse/JETTY-93?page=all ]

Greg Wilkins reassigned JETTY-93:
---------------------------------

    Assignee: nik gonzalez  (was: Greg Wilkins)

> SelectChannelConnector much to slow in windows
> ----------------------------------------------
>
>                 Key: JETTY-93
>                 URL: http://jira.codehaus.org/browse/JETTY-93
>             Project: Jetty
>          Issue Type: Bug
>          Components: HTTP
>         Environment: jetty6 SVN head from 14:15 CEST 19. July 2006
> 2 computers running winxp, connected via 100MBit/s Ethernet
>            Reporter: Yug
>         Assigned To: nik gonzalez
>         Attachments: SlowClient.java, SlowServer.java
>
>
> SelectChannelConnector is extremely slow when client AND server run windows. Serving the same ~14MB jar file takes ~88 seconds (163 kB/s) using SelectChannelConnector and ~1 second (11,8 MB/s) using SocketConnector. 
> When the client uses a smaller buffer than 32kB (see client example) , the download becomes a bit faster (up to 460 kB/s).
> (unfortunately, javaws 1.5 uses 32kB).
> When the server runs on freebsd and the client on windows, I get about 8-9 MB/s using the SelectChannelConnector. 
> I will attach the following:
> - test server which serves the current directory using SelectChannelConnector on port 18080 and SocketConnector on port 18081
> - test client which connects to the server on both ports and measures time and speed
> - a big jarfile which is served
> To reproduce:
> - Insert server hostname in SlowClient.java
> - compile client and server
> - Put SlowServer.class, big.jar and jetty libraries on one windows box and SlowClient.class on another windows box, both being connected via 100MBit ethernet.
> - run server and client

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Re: [jetty-discuss] API or other (J

[<maralc@uo...>]

<br>
<br>
"-- Esta =E9 uma mensagem gerada automaticamente pela caixa postal de maral=
c@... N=E3o h=E1 necessidade de respond=EA-la"
<br>
<br>
Meu email mudou para maralc@...<br><br>N=E3o estou lendo mais aparti=
r deste email.<br><br>Obrigado.<br><br>Maralc
<br>
<br>

Re: [jetty-discuss] Jetty With Push Technology Implementation

[Greg Wilkins <gregw@mo...>]

Sands,

download Jetty 6 and run up the chat demo.
then pull the chat demo apart and work out how it works 
ask questions on #jetty IRC room on codehaus
and then you will understand how to do "push"

cheers


sands wrote:
> Hi! 
> I'm new in Jetty application and still self-studying the basic concept of
> jetty.
> I wanted to implement the jetty using its push technology concept.
> 
> For example given a certain scenario, I had two number x and y... User will
> send request to jetty server to process the addition and then received by
> user/client. Then after a few span of time, without the user sending
> request, jetty must send also multiplication process to the client. The
> scenario is pretty easy but I'm really stuck. I don't know how to start
> using the Jetty 6.0.  
> 
> Can someone help me how to implement step-by-step the jetty with push
> technology given the scenario?
> 

Re: [jetty-discuss] How to hand over objects to WebApplication (embedded Jetty)?

[Greg Wilkins <gregw@mo...>]

Nabbling,

you either have to:

 1)  add your contexts one at time and configure them as you go (then call addWebApplications to add any extras)
 2) have a derived context type that addWebApplications can use
 3) Inspect the getHandlers array afterwards and add your configurations.

cheers


Nabbling wrote:
> And how is it possible to set attributes when using a
> ContextHandlerCollection when adding a full web-application instead of
> single servlets? I have the following code:
> 
> Server server = new Server();
> Connector connector = new SelectChannelConnector();
> connector.setPort(8080);
> server.setConnectors(new Connector[] { connector });
> 
> HandlerCollection handlers = new HandlerCollection();
> ContextHandlerCollection contexts = new ContextHandlerCollection();
> RequestLogHandler requestLogHandler = new RequestLogHandler();
> handlers.setHandlers(new Handler[] { contexts, new DefaultHandler(),
> requestLogHandler });
> server.setHandler(handlers);
> WebAppContext.addWebApplications(server, "./webapps", null, true, false);
> //...
> 
> How can I access the ServletContext.setAttribute(...) in this example? Or do
> I have to use another way to hand over object from the
> jetty-startup-application to a web-application?
> 
> Thanks in advance!

Re: [jetty-discuss] Maven plugin with SSL

[David Yu <dyu@ex...>]

  Hi Richard,

You can create a keystore from scratch by doing the following:
1. cd to your JAVA_HOME\bin directory using commandline.
2. run this line:
keytool -genkey -alias jetty6 -keyalg RSA -keystore 
E:\path\to\your\samplekeystore.keystore

And insert this insdie the <connectors> element

              <connector 
implementation="org.mortbay.jetty.security.SslSocketConnector">
              <port>8443</port>
              <maxIdleTime>60000</maxIdleTime>
              <keystore>e:/path/to/your/samplekeystore.keystore</keystore>
              <password>your keystore password</password>  // this will 
be prompted first (keystore password) after you enter the command above 
(keytool)
              <keyPassword>your keypassword</keyPassword>  // this will 
be prompted last (key password) after you enter the command above (keytool)
            </connector>

P.S. Hoping this is not a double post.  My previous reply was not sent 
successfully for some reason.

Hope this helps,
David

[jetty-discuss] [jira] Assigned: (JETTY-93) SelectChannelConnector much to slow in windows

[Greg Wilkins (JIRA) <jira@co...>]

     [ http://jira.codehaus.org/browse/JETTY-93?page=all ]

Greg Wilkins reassigned JETTY-93:
---------------------------------

    Assignee: Greg Wilkins

> SelectChannelConnector much to slow in windows
> ----------------------------------------------
>
>                 Key: JETTY-93
>                 URL: http://jira.codehaus.org/browse/JETTY-93
>             Project: Jetty
>          Issue Type: Bug
>          Components: HTTP
>         Environment: jetty6 SVN head from 14:15 CEST 19. July 2006
> 2 computers running winxp, connected via 100MBit/s Ethernet
>            Reporter: Yug
>         Assigned To: Greg Wilkins
>         Attachments: SlowClient.java, SlowServer.java
>
>
> SelectChannelConnector is extremely slow when client AND server run windows. Serving the same ~14MB jar file takes ~88 seconds (163 kB/s) using SelectChannelConnector and ~1 second (11,8 MB/s) using SocketConnector. 
> When the client uses a smaller buffer than 32kB (see client example) , the download becomes a bit faster (up to 460 kB/s).
> (unfortunately, javaws 1.5 uses 32kB).
> When the server runs on freebsd and the client on windows, I get about 8-9 MB/s using the SelectChannelConnector. 
> I will attach the following:
> - test server which serves the current directory using SelectChannelConnector on port 18080 and SocketConnector on port 18081
> - test client which connects to the server on both ports and measures time and speed
> - a big jarfile which is served
> To reproduce:
> - Insert server hostname in SlowClient.java
> - compile client and server
> - Put SlowServer.class, big.jar and jetty libraries on one windows box and SlowClient.class on another windows box, both being connected via 100MBit ethernet.
> - run server and client

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jetty-discuss] API or other (JAAS?) recommended 'masquerade' login method

[Ken Johanon <jetty-user@ke...>]

[retry, my last send apparently failed]

Hello,

I believe what I need to do can may only be accomplished at the API
level; that the combination of login requirements cannot be accomplished
using contemporary JAAS/etc methods.

Effectively, I need to allow a 3rd party API to masquerade a user (join
their session with a Principal). Even though that is not servlet
compliant or portable.

What the 3rd party API needs to support (and I am able to right now
using another server that supports a masquerade API) is:

-Login forms: the user must be able to enter any accepted unique
identifier in the 'username' field; this can be the user's assigned
username, OR their email address, OR a X509 DN, divers-license, etc. The
3rd party API performs a database or LDAP lookup using any one of those
inputs, the returns the user's Principal id (a traditional 'username').
If the password matches the user's database / LDAP credentials (hash,
etc), the API then calls the server's 'masquerade' API.

-X509: when SSL client authentication is enabled (in the 'optional
mode') and the user offers a cert... the DN from the cert is validated
against a database and other logic (OCSP, issuer's use-policies, etc),
and if valid, the Principal name is again returned, and passed to the
server's masquerade function for an implicit login.

So the combination of all these requirements seems to require an
API-level (non-portable) interface into the server... a "masquerade"
function... to join a Principal to the HttpSession..

Has anyone done something similar with Jetty? I'd appreciate any
pointers into if/how one could access the server internal APIs... from
the servlet level. Or if anyone knows that this can be done with JAAS, I
would VERY much appreciate being corrected :-)

Thanks in advance,
ken

Re: [jetty-discuss] Maven plugin with SSL

[Jan Bartel <janb@mo...>]

Richard,

FYI

We moved the site over to jetty6 recently and the faq you refer
to was available from the jetty5 site.

The old jetty5 site is still available if you follow the link 
from the new home page on the left hand side menu item "Old jetty5.x"
site.

We are moving over the info that is still relevant from the old
site, but it is taking some time, so thanks for bearing with us
while we do the re-org.

regards
Jan


Richard Wallace wrote:
> Thanks Nik, that worked perfectly.  The only problem I still had was I
> wasn't sure how to create my keystore and such.  I did a google search
> for Jetty and SSL but the only thing I found was a reference to a FAQ on
> the Jetty site that was no longer valid.  Thank goodness for google
> cache!  Is there an alternative location for the FAQs that I missed. 
> This is the url that I was trying to get to
> http://www.mortbay.org/jetty/faq?s=400-Security&t=ssl.  And here's the
> cached page for anyone interested:
> http://72.14.203.104/search?q=cache:p07HSRYlYdsJ:www.mortbay.org/jetty/faq%3Fs%3D400-Security%26t%3Dssl+jetty+ssl&hl=en&gl=us&ct=clnk&cd=1&client=firefox.
> 
> Thanks again,
> Rich
> 
> Nik Gonzalez wrote:
> 
>>Hi Richard,
>>
>>Try inserting the following into the configuration tag of your 
>>maven-jetty-plugin inside the pom:
>>
>>          <connectors>
>>            <connector 
>>implementation="org.mortbay.jetty.nio.SelectChannelConnector">
>>              <port>8080</port>
>>              <maxIdleTime>60000</maxIdleTime>
>>            </connector>
>>            <connector 
>>implementation="org.mortbay.jetty.security.SslSocketConnector">
>>              <port>8443</port>
>>              <maxIdleTime>30000</maxIdleTime>
>>              <keystore>C:\jeprox\jetty6\etc\keystore</keystore>
>>              <password>OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4</password>
>>              <keyPassword>OBF:1u2u1wml1z7s1z7a1wnl1u2g</keyPassword>
>>              <truststore>C:\jeprox\jetty6\etc\keystore\</truststore>
>>              
>><trustPassword>OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4</trustPassword>
>>              <excludeCipherSuites>
>>                
>><excludeCipherSuite>SSL_RSA_WITH_3DES_EDE_CBC_SHA</excludeCipherSuite>
>>                
>><excludeCipherSuite>SSL_DHE_RSA_WITH_DES_CBC_SHA</excludeCipherSuite>
>>                
>><excludeCipherSuite>SSL_DHE_DSS_WITH_DES_CBC_SHA</excludeCipherSuite>
>>              </excludeCipherSuites>
>>            </connector>
>>          </connectors>
>>
>>http://docs.codehaus.org/display/JETTY/SSL+Cipher+Suites has been 
>>updated. Kindly check it out again. Instead of the former implementation 
>>that lets you specify a list of enabled cipher suites, the new one lets 
>>you disable a list of cipher suites. There's also an update on the 
>>config example.
>>
>>Thanks!
>>Nik
>>
>>Richard Wallace wrote:
>>  
>>
>>>Hello,
>>>
>>>I'm trying to get the maven plugin working so that I can get rid of
>>>having to do a "mvn tomcat:undeploy clean && mvn tomcat:deploy"
>>>whenever I change something in a configuration file or class and I
>>>don't have to copy over the jsps and whatnot when I change those.  The
>>>app I'm working on now requires SSL for some of the more secure areas
>>>of the app.
>>>
>>>I tried creating a jetty.xml file with the following configuration
>>>(gleaned from http://docs.codehaus.org/display/JETTY/SSL+Cipher+Suites):
>>>
>>><?xml version="1.0"  encoding="ISO-8859-1"?>
>>><!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN"
>>>"http://jetty.mortbay.org/configure.dtd">;
>>>
>>><Configure class="org.mortbay.jetty.Server">
>>>  <Item>
>>>    <New class="org.mortbay.jetty.security.SslSocketConnector">
>>>      <Set name="Port">8443</Set>
>>>      <Set name="maxIdleTime">30000</Set>
>>>      <Set name="Keystore">
>>>        <SystemProperty name="jetty.home" default="." />
>>>        /etc/keystore
>>>      </Set>
>>>      <Set name="Password">OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4</Set>
>>>      <Set name="KeyPassword">OBF:1u2u1wml1z7s1z7a1wnl1u2g</Set>
>>>      <!--you can specify the cipher suites with the suitable key
>>>lengths in the following section. Only supported cipher suites should
>>>be listed in this section. -->
>>>      <Set name="CipherSuites">
>>>        <Array type="java.lang.String">
>>>          <Item>SSL_RSA_WITH_RC4_128_MD5</Item>
>>>          <Item>SSL_RSA_WITH_RC4_128_SHA</Item>
>>>          <Item>SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA</Item>
>>>        </Array>
>>>      </Set>
>>>    </New>
>>>  </Item>
>>></Configure>
>>>
>>>For some reason it doesn't seem to like the Configure->Item->New
>>>hierarchy, tho it seems valid in the dtd from what I read.  I tried
>>>removing the surrounding <Item> element but Jetty just seemed to
>>>ignore the <New> element.
>>>
>>>I noticed that you can also specify the <connectors> in the the
>>><configuration> element of the jetty plugin in the pom file itself.  I
>>>started to try and do that but then wasn't sure what to do about the
>>><Set name="CipherSuites"> element and its nested <Array> element.
>>>
>>>So, how should I be going about configuring jetty so that when I do a
>>>"maven jetty:run" it creates a SSL connector in addition to the
>>>standard HTTP connector?
>>>
>>>Thanks,
>>>Rich
>>>
>>>
>>>-------------------------------------------------------------------------
>>>Take Surveys. Earn Cash. Influence the Future of IT
>>>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>>>opinions on IT & business topics through brief surveys -- and earn cash
>>>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>>_______________________________________________
>>>jetty-discuss mailing list
>>>jetty-discuss@...
>>>https://lists.sourceforge.net/lists/listinfo/jetty-discuss
>>>
>>>  
>>>    
>>
>>
>>-------------------------------------------------------------------------
>>Take Surveys. Earn Cash. Influence the Future of IT
>>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>>opinions on IT & business topics through brief surveys -- and earn cash
>>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>_______________________________________________
>>jetty-discuss mailing list
>>jetty-discuss@...
>>https://lists.sourceforge.net/lists/listinfo/jetty-discuss
>>  
> 
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[jetty-discuss] Compiling Jetty from the Sources

[Alexander Maslov <alexander.maslov@gm...>]

Hi.

I've been using jetty-jboss quite a long time, thx for your product.

jetty-5.1.11RC0-jboss.4.0.2.sar compiled with Java 1.5 so it can not
lunched on 1.4 which is quite common for servers.
So I tried to build it from sources and got the same result (I was
using 1.5 also).
After some "investigation" I found out that build.xml files for extras
does not use (javac.target, javac.debug ....) parameters from root's
ant.properties. So event if I put javac.target=1.4 in ant.properties
file, extras are compiled with default compiler's setting. And as a
result you can not run jett-jboss under 1.4.
Changing build.xml files (<javac > ant's task) in extras projects in a
way that ant pay attentions to javac properties from the main
ant.properties file solved the problem.

Would be nice if some body checks those things, because now if you
have 1.4 and download jetty-jboss from the sourcefoge it is simply not
working

Best regards,
 Alex

[jetty-discuss] [ jetty-Bugs-1502154 ] SslListene should support more KeyManagerFactory

[SourceForge.net <noreply@so...>]

Bugs item #1502154, was opened at 2006-06-07 10:26
Message generated for change (Settings changed) made by gregwilkins
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=107322&aid=1502154&group_id=7322

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: HTTP protocol
Group: Jetty3
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: maomao (maomaode)
Assigned to: Nobody/Anonymous (nobody)
Summary: SslListene should support more KeyManagerFactory 

Initial Comment:
SSLListener should support more KeyManagerFactory not
only SunX509.
_alogrithm should be :
java.security.Security.getProperty("ssl.KeyManagerFactory.algorithm");
to support other providers KeyManager.

----------------------------------------------------------------------

>Comment By: Greg Wilkins (gregwilkins)
Date: 2006-07-26 00:09

Message:
Logged In: YES 
user_id=44062

fixed in cvs


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=107322&aid=1502154&group_id=7322