Securing Hudson

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Securing Hudson

David Weintraub-4
Okay:

I'm trying to use ArgumentRealm security, but still having problems.

I'm starting hudson with the following command:

nohup $JAVA -jar hudson.jar --httpPort=$HTTP_PORT --javaHome=$JAVA_HOME
--argumentsRealm.passwd.admin=build --argumentRealm.roles.admin=admin &

I attempted to define one user, "admin", with a password of "build", and
a role of "admin".

Here's the startup log for hudson:

[Winstone 2007/10/24 12:19:31] - Beginning extraction from war file
[Winstone 2007/10/24 12:19:33] - No webapp classes folder found -
/tmp/winstone/hudson.jar/WEB-INF/classes
[Winstone 2007/10/24 12:19:33] - WARNING: No roles detected in
configuration for user admin
hudson home directory: /solbright/tools/build/hudson
[Winstone 2007/10/24 12:19:33] - AJP13 Listener started: port=8009
[Winstone 2007/10/24 12:19:33] - HTTP Listener started: port=8090
[Winstone 2007/10/24 12:19:33] - Winstone Servlet Engine v0.9.9 running:
controlPort=disabled
Oct 24, 2007 12:19:33 PM hudson.PluginWrapper <init>
INFO: Loading plugin: /solbright/tools/build/hudson/plugins/scp.hpi
Oct 24, 2007 12:19:33 PM hudson.PluginWrapper <init>
INFO: Loading plugin: /solbright/tools/build/hudson/plugins/jira.hpi
Oct 24, 2007 12:19:33 PM hudson.TcpSlaveAgentListener <init>
INFO: JNLP slave agent listener started on TCP port 48574
Oct 24, 2007 12:19:34 PM hudson.model.Hudson load
INFO: Took 518 ms to load
Oct 24, 2007 12:20:34 PM hudson.triggers.SCMTrigger$Runner runPolling
INFO: Polling SCM changes of DSP

Note line #3: "WARNING: No roles detected in configuration for user
admin". I thought I defined the role on the command line.

Now, I click on the "login" link which takes me to the LoginEntry page.
I enter the user ID "admin" and password "build". The screen goes blank,
and a "logout" link appears on the top right corner. Good? No. Here's
the Hudson log:

[Winstone 2007/10/24 12:29:55] - Called getInputStream after
getParameter ... error
[Winstone 2007/10/24 12:29:55] - Called getInputStream after
getParameter ... error
[Winstone 2007/10/24 12:29:55] - Untrapped Error in Servlet
java.lang.IllegalStateException: Called RequestDispatcher.forward() on
committed response
        at
winstone.RequestDispatcher.forward(RequestDispatcher.java:263)
        at
winstone.auth.FormAuthenticationHandler.validatePossibleAuthenticationRe
sponse(FormAuthenticationHandler.java:191)
        at
winstone.auth.BaseAuthenticationHandler.processAuthentication(BaseAuthen
ticationHandler.java:85)
        at
winstone.auth.FormAuthenticationHandler.processAuthentication(FormAuthen
ticationHandler.java:99)
        at
winstone.RequestDispatcher.continueAfterSecurityCheck(RequestDispatcher.
java:349)
        at
winstone.RequestDispatcher.forward(RequestDispatcher.java:323)
        at
winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:2
44)
        at
winstone.RequestHandlerThread.run(RequestHandlerThread.java:150)
        at java.lang.Thread.run(Thread.java:595)

When I go back to the Main page, again the "login" link is highlighted.
If I go to http://myserver:8090/configure, I get a 403 error and the
following log entries:

javax.servlet.ServletException: Unauthorized access
        at hudson.Functions.adminCheck(Functions.java:406)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at
org.apache.commons.jexl.util.introspection.UberspectImpl$VelMethodImpl.i
nvoke(UberspectImpl.java:255)
        at
org.apache.commons.jexl.parser.ASTMethod.execute(ASTMethod.java:104)
        at
org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:82
)
        at
org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:56)
        at
org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReference
Expression.java:50)
        at
org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:79)
        at
org.apache.commons.jelly.expression.jexl.JexlExpression.evaluate(JexlExp
ression.java:69)
        at
org.apache.commons.jelly.impl.ExpressionScript.run(ExpressionScript.java
:66)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
        at
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
        at
org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:65)
        at
org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:1
12)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
        at
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
        at
org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:65)
        at
org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:1
12)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
        at
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
        at
org.apache.commons.jelly.tags.core.JellyTag.doTag(JellyTag.java:45)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
        at
org.apache.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:80)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
        at
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
        at
org.apache.commons.jelly.tags.core.JellyTag.doTag(JellyTag.java:45)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
        at
org.kohsuke.stapler.jelly.JellyClassTearOff.invokeScript(JellyClassTearO
ff.java:78)
        at org.kohsuke.stapler.MetaClass$3.dispatch(MetaClass.java:111)
        at org.kohsuke.stapler.Stapler.invoke(Stapler.java:291)
        at org.kohsuke.stapler.Stapler.invoke(Stapler.java:228)
        at org.kohsuke.stapler.Stapler.service(Stapler.java:76)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:45)
        at
winstone.ServletConfiguration.execute(ServletConfiguration.java:249)
        at
winstone.RequestDispatcher.forward(RequestDispatcher.java:335)
        at
winstone.RequestDispatcher.doFilter(RequestDispatcher.java:378)
        at
hudson.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java
:79)
        at
winstone.FilterConfiguration.execute(FilterConfiguration.java:195)
        at
winstone.RequestDispatcher.doFilter(RequestDispatcher.java:368)
        at
winstone.RequestDispatcher.forward(RequestDispatcher.java:333)
        at
winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:2
44)
        at
winstone.RequestHandlerThread.run(RequestHandlerThread.java:150)
        at java.lang.Thread.run(Thread.java:595)

So, exactly what am I doing wrong?

--
David Weintraub
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Securing Hudson

Kohsuke Kawaguchi
Administrator

I think this is the same issue as in
http://www.nabble.com/authentification-with-winston-tf3851709.html#a10911043

Notice that you made a typo. It's
--argumentsRealm.roles.admin=admin, and not
--argumentRealm.roles.admin=admin

Winstone really needs to do a better job at reporting errors like this
--- in fact looking at the error report in Winstone it seems like the
issue is fixed but new version has not yet released.

Maybe Hudson should start picking up the trunk version of Winstone.


David Weintraub wrote:

> Okay:
>
> I'm trying to use ArgumentRealm security, but still having problems.
>
> I'm starting hudson with the following command:
>
> nohup $JAVA -jar hudson.jar --httpPort=$HTTP_PORT --javaHome=$JAVA_HOME
> --argumentsRealm.passwd.admin=build --argumentRealm.roles.admin=admin &
>
> I attempted to define one user, "admin", with a password of "build", and
> a role of "admin".
>
> Here's the startup log for hudson:
>
> [Winstone 2007/10/24 12:19:31] - Beginning extraction from war file
> [Winstone 2007/10/24 12:19:33] - No webapp classes folder found -
> /tmp/winstone/hudson.jar/WEB-INF/classes
> [Winstone 2007/10/24 12:19:33] - WARNING: No roles detected in
> configuration for user admin
> hudson home directory: /solbright/tools/build/hudson
> [Winstone 2007/10/24 12:19:33] - AJP13 Listener started: port=8009
> [Winstone 2007/10/24 12:19:33] - HTTP Listener started: port=8090
> [Winstone 2007/10/24 12:19:33] - Winstone Servlet Engine v0.9.9 running:
> controlPort=disabled
> Oct 24, 2007 12:19:33 PM hudson.PluginWrapper <init>
> INFO: Loading plugin: /solbright/tools/build/hudson/plugins/scp.hpi
> Oct 24, 2007 12:19:33 PM hudson.PluginWrapper <init>
> INFO: Loading plugin: /solbright/tools/build/hudson/plugins/jira.hpi
> Oct 24, 2007 12:19:33 PM hudson.TcpSlaveAgentListener <init>
> INFO: JNLP slave agent listener started on TCP port 48574
> Oct 24, 2007 12:19:34 PM hudson.model.Hudson load
> INFO: Took 518 ms to load
> Oct 24, 2007 12:20:34 PM hudson.triggers.SCMTrigger$Runner runPolling
> INFO: Polling SCM changes of DSP
>
> Note line #3: "WARNING: No roles detected in configuration for user
> admin". I thought I defined the role on the command line.
>
> Now, I click on the "login" link which takes me to the LoginEntry page.
> I enter the user ID "admin" and password "build". The screen goes blank,
> and a "logout" link appears on the top right corner. Good? No. Here's
> the Hudson log:
>
> [Winstone 2007/10/24 12:29:55] - Called getInputStream after
> getParameter ... error
> [Winstone 2007/10/24 12:29:55] - Called getInputStream after
> getParameter ... error
> [Winstone 2007/10/24 12:29:55] - Untrapped Error in Servlet
> java.lang.IllegalStateException: Called RequestDispatcher.forward() on
> committed response
>         at
> winstone.RequestDispatcher.forward(RequestDispatcher.java:263)
>         at
> winstone.auth.FormAuthenticationHandler.validatePossibleAuthenticationRe
> sponse(FormAuthenticationHandler.java:191)
>         at
> winstone.auth.BaseAuthenticationHandler.processAuthentication(BaseAuthen
> ticationHandler.java:85)
>         at
> winstone.auth.FormAuthenticationHandler.processAuthentication(FormAuthen
> ticationHandler.java:99)
>         at
> winstone.RequestDispatcher.continueAfterSecurityCheck(RequestDispatcher.
> java:349)
>         at
> winstone.RequestDispatcher.forward(RequestDispatcher.java:323)
>         at
> winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:2
> 44)
>         at
> winstone.RequestHandlerThread.run(RequestHandlerThread.java:150)
>         at java.lang.Thread.run(Thread.java:595)
>
> When I go back to the Main page, again the "login" link is highlighted.
> If I go to http://myserver:8090/configure, I get a 403 error and the
> following log entries:
>
> javax.servlet.ServletException: Unauthorized access
>         at hudson.Functions.adminCheck(Functions.java:406)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
> a:39)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
> Impl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at
> org.apache.commons.jexl.util.introspection.UberspectImpl$VelMethodImpl.i
> nvoke(UberspectImpl.java:255)
>         at
> org.apache.commons.jexl.parser.ASTMethod.execute(ASTMethod.java:104)
>         at
> org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:82
> )
>         at
> org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:56)
>         at
> org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReference
> Expression.java:50)
>         at
> org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:79)
>         at
> org.apache.commons.jelly.expression.jexl.JexlExpression.evaluate(JexlExp
> ression.java:69)
>         at
> org.apache.commons.jelly.impl.ExpressionScript.run(ExpressionScript.java
> :66)
>         at
> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
>         at
> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
>         at
> org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
>         at
> org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:65)
>         at
> org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:1
> 12)
>         at
> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
>         at
> org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
>         at
> org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:65)
>         at
> org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:1
> 12)
>         at
> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
>         at
> org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
>         at
> org.apache.commons.jelly.tags.core.JellyTag.doTag(JellyTag.java:45)
>         at
> org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
>         at
> org.apache.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:80)
>         at
> org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
>         at
> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
>         at
> org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
>         at
> org.apache.commons.jelly.tags.core.JellyTag.doTag(JellyTag.java:45)
>         at
> org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
>         at
> org.kohsuke.stapler.jelly.JellyClassTearOff.invokeScript(JellyClassTearO
> ff.java:78)
>         at org.kohsuke.stapler.MetaClass$3.dispatch(MetaClass.java:111)
>         at org.kohsuke.stapler.Stapler.invoke(Stapler.java:291)
>         at org.kohsuke.stapler.Stapler.invoke(Stapler.java:228)
>         at org.kohsuke.stapler.Stapler.service(Stapler.java:76)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:45)
>         at
> winstone.ServletConfiguration.execute(ServletConfiguration.java:249)
>         at
> winstone.RequestDispatcher.forward(RequestDispatcher.java:335)
>         at
> winstone.RequestDispatcher.doFilter(RequestDispatcher.java:378)
>         at
> hudson.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java
> :79)
>         at
> winstone.FilterConfiguration.execute(FilterConfiguration.java:195)
>         at
> winstone.RequestDispatcher.doFilter(RequestDispatcher.java:368)
>         at
> winstone.RequestDispatcher.forward(RequestDispatcher.java:333)
>         at
> winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:2
> 44)
>         at
> winstone.RequestHandlerThread.run(RequestHandlerThread.java:150)
>         at java.lang.Thread.run(Thread.java:595)
>
> So, exactly what am I doing wrong?
>
> --
> David Weintraub
> [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Re: Securing Hudson

David Weintraub-4
Yes, I found out that I had dropped the "s" in the parameter. When I put
the "s" in (and I changed the administrator's user name from "admin" to
"hudson") everything works fine.

I added a new section to the Securing Hudson wiki page called "Quick and
Simple Security". I see that you already modified the page, correcting
some of the errors I made. Thank you.

BTW, I do have one question: We tell people to run "java -jar
hudson.war", but when I downloaded Hudson, it was a jarfile and not a
warfile. I am not a J2EE expert, and it looks like hudson.jar is in
warfile format, but if Hudson is distributed as hudson.jar, why do we
tell people to execute -jar hudson.war? Am I suppose to rename
hudson.jar to hudson.war?

-----Original Message-----
From: Kohsuke Kawaguchi [mailto:[hidden email]]
Sent: Wednesday, October 24, 2007 8:28 PM
To: [hidden email]
Subject: Re: Securing Hudson


I think this is the same issue as in
http://www.nabble.com/authentification-with-winston-tf3851709.html#a1091
1043

Notice that you made a typo. It's
--argumentsRealm.roles.admin=admin, and not
--argumentRealm.roles.admin=admin

Winstone really needs to do a better job at reporting errors like this
--- in fact looking at the error report in Winstone it seems like the
issue is fixed but new version has not yet released.

Maybe Hudson should start picking up the trunk version of Winstone.


David Weintraub wrote:
> Okay:
>
> I'm trying to use ArgumentRealm security, but still having problems.
>
> I'm starting hudson with the following command:
>
> nohup $JAVA -jar hudson.jar --httpPort=$HTTP_PORT
--javaHome=$JAVA_HOME
> --argumentsRealm.passwd.admin=build --argumentRealm.roles.admin=admin
&
>
> I attempted to define one user, "admin", with a password of "build",
and

> a role of "admin".
>
> Here's the startup log for hudson:
>
> [Winstone 2007/10/24 12:19:31] - Beginning extraction from war file
> [Winstone 2007/10/24 12:19:33] - No webapp classes folder found -
> /tmp/winstone/hudson.jar/WEB-INF/classes
> [Winstone 2007/10/24 12:19:33] - WARNING: No roles detected in
> configuration for user admin
> hudson home directory: /solbright/tools/build/hudson
> [Winstone 2007/10/24 12:19:33] - AJP13 Listener started: port=8009
> [Winstone 2007/10/24 12:19:33] - HTTP Listener started: port=8090
> [Winstone 2007/10/24 12:19:33] - Winstone Servlet Engine v0.9.9
running:

> controlPort=disabled
> Oct 24, 2007 12:19:33 PM hudson.PluginWrapper <init>
> INFO: Loading plugin: /solbright/tools/build/hudson/plugins/scp.hpi
> Oct 24, 2007 12:19:33 PM hudson.PluginWrapper <init>
> INFO: Loading plugin: /solbright/tools/build/hudson/plugins/jira.hpi
> Oct 24, 2007 12:19:33 PM hudson.TcpSlaveAgentListener <init>
> INFO: JNLP slave agent listener started on TCP port 48574
> Oct 24, 2007 12:19:34 PM hudson.model.Hudson load
> INFO: Took 518 ms to load
> Oct 24, 2007 12:20:34 PM hudson.triggers.SCMTrigger$Runner runPolling
> INFO: Polling SCM changes of DSP
>
> Note line #3: "WARNING: No roles detected in configuration for user
> admin". I thought I defined the role on the command line.
>
> Now, I click on the "login" link which takes me to the LoginEntry
page.
> I enter the user ID "admin" and password "build". The screen goes
blank,

> and a "logout" link appears on the top right corner. Good? No. Here's
> the Hudson log:
>
> [Winstone 2007/10/24 12:29:55] - Called getInputStream after
> getParameter ... error
> [Winstone 2007/10/24 12:29:55] - Called getInputStream after
> getParameter ... error
> [Winstone 2007/10/24 12:29:55] - Untrapped Error in Servlet
> java.lang.IllegalStateException: Called RequestDispatcher.forward() on
> committed response
>         at
> winstone.RequestDispatcher.forward(RequestDispatcher.java:263)
>         at
>
winstone.auth.FormAuthenticationHandler.validatePossibleAuthenticationRe
> sponse(FormAuthenticationHandler.java:191)
>         at
>
winstone.auth.BaseAuthenticationHandler.processAuthentication(BaseAuthen
> ticationHandler.java:85)
>         at
>
winstone.auth.FormAuthenticationHandler.processAuthentication(FormAuthen
> ticationHandler.java:99)
>         at
>
winstone.RequestDispatcher.continueAfterSecurityCheck(RequestDispatcher.
> java:349)
>         at
> winstone.RequestDispatcher.forward(RequestDispatcher.java:323)
>         at
>
winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:2
> 44)
>         at
> winstone.RequestHandlerThread.run(RequestHandlerThread.java:150)
>         at java.lang.Thread.run(Thread.java:595)
>
> When I go back to the Main page, again the "login" link is
highlighted.
> If I go to http://myserver:8090/configure, I get a 403 error and the
> following log entries:
>
> javax.servlet.ServletException: Unauthorized access
>         at hudson.Functions.adminCheck(Functions.java:406)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
> a:39)
>         at
>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
> Impl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at
>
org.apache.commons.jexl.util.introspection.UberspectImpl$VelMethodImpl.i
> nvoke(UberspectImpl.java:255)
>         at
> org.apache.commons.jexl.parser.ASTMethod.execute(ASTMethod.java:104)
>         at
>
org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:82
> )
>         at
>
org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:56)
>         at
>
org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReference
> Expression.java:50)
>         at
>
org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:79)
>         at
>
org.apache.commons.jelly.expression.jexl.JexlExpression.evaluate(JexlExp
> ression.java:69)
>         at
>
org.apache.commons.jelly.impl.ExpressionScript.run(ExpressionScript.java

> :66)
>         at
> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
>         at
> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
>         at
> org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
>         at
> org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:65)
>         at
>
org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:1
> 12)
>         at
> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
>         at
> org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
>         at
> org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:65)
>         at
>
org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:1

> 12)
>         at
> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
>         at
> org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
>         at
> org.apache.commons.jelly.tags.core.JellyTag.doTag(JellyTag.java:45)
>         at
> org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
>         at
> org.apache.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:80)
>         at
> org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
>         at
> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
>         at
> org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
>         at
> org.apache.commons.jelly.tags.core.JellyTag.doTag(JellyTag.java:45)
>         at
> org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
>         at
>
org.kohsuke.stapler.jelly.JellyClassTearOff.invokeScript(JellyClassTearO
> ff.java:78)
>         at
org.kohsuke.stapler.MetaClass$3.dispatch(MetaClass.java:111)

>         at org.kohsuke.stapler.Stapler.invoke(Stapler.java:291)
>         at org.kohsuke.stapler.Stapler.invoke(Stapler.java:228)
>         at org.kohsuke.stapler.Stapler.service(Stapler.java:76)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:45)
>         at
> winstone.ServletConfiguration.execute(ServletConfiguration.java:249)
>         at
> winstone.RequestDispatcher.forward(RequestDispatcher.java:335)
>         at
> winstone.RequestDispatcher.doFilter(RequestDispatcher.java:378)
>         at
>
hudson.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java
> :79)
>         at
> winstone.FilterConfiguration.execute(FilterConfiguration.java:195)
>         at
> winstone.RequestDispatcher.doFilter(RequestDispatcher.java:368)
>         at
> winstone.RequestDispatcher.forward(RequestDispatcher.java:333)
>         at
>
winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:2

> 44)
>         at
> winstone.RequestHandlerThread.run(RequestHandlerThread.java:150)
>         at java.lang.Thread.run(Thread.java:595)
>
> So, exactly what am I doing wrong?
>
> --
> David Weintraub
> [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Securing Hudson

Stephan Zeissler (KUTTIG)
Looking at
https://hudson.dev.java.net/servlets/ProjectDocumentList?folderID=2761&expandFolder=2761&folderID=0 
all Links point to a hudson.war
Maybe your download client guess the extension from the content type?

- Stephan

David Weintraub schrieb:
> BTW, I do have one question: We tell people to run "java -jar
> hudson.war", but when I downloaded Hudson, it was a jarfile and not a
> warfile. I am not a J2EE expert, and it looks like hudson.jar is in
> warfile format, but if Hudson is distributed as hudson.jar, why do we
> tell people to execute -jar hudson.war? Am I suppose to rename
> hudson.jar to hudson.war?
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

stephan.zeissler.vcf (381 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Re: Securing Hudson

David Weintraub-4
I just checked, and you're right. I did a download (to verify that my
Windows machine wasn't changing the suffix), it downloaded as
"hudson.war".

However, last week when I did the download last week, I could have sworn
it was hudson.jar.

-----Original Message-----
From: Stephan Zeissler (KUTTIG) [mailto:[hidden email]]
Sent: Thursday, October 25, 2007 10:13 AM
To: [hidden email]
Subject: Re: Securing Hudson

Looking at
https://hudson.dev.java.net/servlets/ProjectDocumentList?folderID=2761&e
xpandFolder=2761&folderID=0
all Links point to a hudson.war
Maybe your download client guess the extension from the content type?

- Stephan

David Weintraub schrieb:
> BTW, I do have one question: We tell people to run "java -jar
> hudson.war", but when I downloaded Hudson, it was a jarfile and not a
> warfile. I am not a J2EE expert, and it looks like hudson.jar is in
> warfile format, but if Hudson is distributed as hudson.jar, why do we
> tell people to execute -jar hudson.war? Am I suppose to rename
> hudson.jar to hudson.war?
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Securing Hudson

Stephan Zeissler (KUTTIG)
Maybe kohsuke did a wrong upload and fixed it in quiet? :P

- Stephan

David Weintraub schrieb:

> I just checked, and you're right. I did a download (to verify that my
> Windows machine wasn't changing the suffix), it downloaded as
> "hudson.war".
>
> However, last week when I did the download last week, I could have sworn
> it was hudson.jar.
>
> -----Original Message-----
> From: Stephan Zeissler (KUTTIG) [mailto:[hidden email]]
> Sent: Thursday, October 25, 2007 10:13 AM
> To: [hidden email]
> Subject: Re: Securing Hudson
>
> Looking at
> https://hudson.dev.java.net/servlets/ProjectDocumentList?folderID=2761&e
> xpandFolder=2761&folderID=0
> all Links point to a hudson.war
> Maybe your download client guess the extension from the content type?
>
> - Stephan
>
> David Weintraub schrieb:
>  
>> BTW, I do have one question: We tell people to run "java -jar
>> hudson.war", but when I downloaded Hudson, it was a jarfile and not a
>> warfile. I am not a J2EE expert, and it looks like hudson.jar is in
>> warfile format, but if Hudson is distributed as hudson.jar, why do we
>> tell people to execute -jar hudson.war? Am I suppose to rename
>> hudson.jar to hudson.war?
>>  
>>    
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>  
--
Stephan Zeissler
Software-Development

KUTTIG Computeranwendungen GmbH
Frankfurter Stra├če 35
53840 Troisdorf
MOB +49 (173) 7207900
FON +49 (2241) 9833-413
FAX +49 (2241) 9833-100
EMAIL [hidden email]
WEB www.kuttig.com
GF Dipl.-Kfm. Klaus Kuttig
Michael Wessels
HR Siegburg Nr 2848


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

stephan.zeissler.vcf (381 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Securing Hudson

Kohsuke Kawaguchi
Administrator
Stephan Zeissler (KUTTIG) wrote:
> Maybe kohsuke did a wrong upload and fixed it in quiet? :P

I do all uploads from a script, so I don't think it's possible.
Maybe David has downloaded from a folder for JNLP, which serves
hudson.jar, because Java Web Start relies on file extensions.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Securing Hudson

Qazwart-2
You could be right. I click on the "Download" link and the folders are
presented as:

Hudson
   Plugins
   Releases
      JNLP
      Old-Releases
      Source Bundles
   Snapshots

With this arrangement, it looks like the JNLP folder contains the
releases. Opening up JNLP gives you a hudson.jar file to download. I
didn't write down the steps I took, but I can imagine getting confused
and thinking the release is in the JNLP folder and not the Releases
folder itself.

Wonder if other people may have made the same mistake.

On 10/29/07, Kohsuke Kawaguchi <[hidden email]> wrote:

> Stephan Zeissler (KUTTIG) wrote:
> > Maybe kohsuke did a wrong upload and fixed it in quiet? :P
>
> I do all uploads from a script, so I don't think it's possible.
> Maybe David has downloaded from a folder for JNLP, which serves
> hudson.jar, because Java Web Start relies on file extensions.
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems                   [hidden email]
>
>


--
--
David Weintraub
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Securing Hudson

Kohsuke Kawaguchi
Administrator
David Weintraub wrote:

> You could be right. I click on the "Download" link and the folders are
> presented as:
>
> Hudson
>    Plugins
>    Releases
>       JNLP
>       Old-Releases
>       Source Bundles
>    Snapshots
>
> With this arrangement, it looks like the JNLP folder contains the
> releases. Opening up JNLP gives you a hudson.jar file to download. I
> didn't write down the steps I took, but I can imagine getting confused
> and thinking the release is in the JNLP folder and not the Releases
> folder itself.
>
> Wonder if other people may have made the same mistake.
Maybe I should change the top-page download link to just download the
war right away.

I don't think most people need to see the archives --- they just want
the latest & greatest, right?

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Securing Hudson

Qazwart-2
I think what threw me off is that you click on the "plus" to expand
the Releases folder, and you get three sub-folders: JNLP,
Old-Releases, and Source Bundles.

I knew I didn't want an Old-Release or the Source, so I clicked on the
JNLP folder. There sits a current release of hudson.jar which does
seem to work if you run it from directly from Winstone.

I guess you could simply download the latest release. If I want
something else, there is a "download" link on the other side. However,
I think these might be better solutions:

* Move the JNLP, Old-Releases, and Source Bundles directories out of
the Release folder. That way, it becomes obvious that you have to
click on the Release folder to see the releases.

* Or, you could have the download link go to
<https://hudson.dev.java.net/servlets/ProjectDocumentList?folderID=2761>.
This will show you the list of all the releases. Plus, you still have
the navigation folders on the lefthand side in case you want to see
the source too.

On 10/30/07, Kohsuke Kawaguchi <[hidden email]> wrote:

> David Weintraub wrote:
> > You could be right. I click on the "Download" link and the folders are
> > presented as:
> >
> > Hudson
> >    Plugins
> >    Releases
> >       JNLP
> >       Old-Releases
> >       Source Bundles
> >    Snapshots
> >
> > With this arrangement, it looks like the JNLP folder contains the
> > releases. Opening up JNLP gives you a hudson.jar file to download. I
> > didn't write down the steps I took, but I can imagine getting confused
> > and thinking the release is in the JNLP folder and not the Releases
> > folder itself.
> >
> > Wonder if other people may have made the same mistake.
>
> Maybe I should change the top-page download link to just download the
> war right away.
>
> I don't think most people need to see the archives --- they just want
> the latest & greatest, right?
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems                   [hidden email]
>
>


--
--
David Weintraub
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Securing Hudson

Kohsuke Kawaguchi
Administrator
David Weintraub wrote:

> I think what threw me off is that you click on the "plus" to expand
> the Releases folder, and you get three sub-folders: JNLP,
> Old-Releases, and Source Bundles.
>
> I knew I didn't want an Old-Release or the Source, so I clicked on the
> JNLP folder. There sits a current release of hudson.jar which does
> seem to work if you run it from directly from Winstone.
>
> I guess you could simply download the latest release. If I want
> something else, there is a "download" link on the other side. However,
> I think these might be better solutions:
>
> * Move the JNLP, Old-Releases, and Source Bundles directories out of
> the Release folder. That way, it becomes obvious that you have to
> click on the Release folder to see the releases.
>
> * Or, you could have the download link go to
> <https://hudson.dev.java.net/servlets/ProjectDocumentList?folderID=2761>.
> This will show you the list of all the releases. Plus, you still have
> the navigation folders on the lefthand side in case you want to see
> the source too.
Thanks. This seems like the easiest for now, so I just made this change.


--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment