From darran.lofthouse at jboss.com Mon Mar 3 08:35:34 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Mon, 03 Mar 2014 13:35:34 +0000 Subject: [undertow-dev] CachedAuthenticatedSessionMechanism should return NOT_ATTEMPTED? In-Reply-To: <53112C3D.9060706@redhat.com> References: <53112C3D.9060706@redhat.com> Message-ID: <53148526.9090808@jboss.com> I think the problem here is if we return NOT_ATTEMPTED in some scenarios where a user was previously authenticated against a web app this could be quietly lost. Returning NOT_AUTHENTICATED on the other hand forces the challenge phase again. Is caching against the session really the correct approach for your mechanism? For a number of mechanisms caching against the session is actually a bad habit carried over from Tomcat, instead alternative caching should be employed to optimise subsequent authentication token validation. The places where we do need to cache against the session are for form based authentication mechanisms as not caching would result in a prompt to the user on every request, for other mechanisms where we have tokens coming from the browser we don't cache against the session. Regards, Darran Lofthouse. On 01/03/14 00:39, Bill Burke wrote: > If IdentityManager.verify(Account) returns null, shouldn't > CachedAuthenticatedSessionMechanism return NOT_ATTEMPTED instead of > aborting and returning 403/NOT_AUTHENTICATED? I was expecting that > returning null would start the auth process again. > > > > From bburke at redhat.com Mon Mar 3 10:18:04 2014 From: bburke at redhat.com (Bill Burke) Date: Mon, 03 Mar 2014 10:18:04 -0500 Subject: [undertow-dev] CachedAuthenticatedSessionMechanism should return NOT_ATTEMPTED? In-Reply-To: <53148526.9090808@jboss.com> References: <53112C3D.9060706@redhat.com> <53148526.9090808@jboss.com> Message-ID: <53149D2C.90703@redhat.com> On 3/3/2014 8:35 AM, Darran Lofthouse wrote: > I think the problem here is if we return NOT_ATTEMPTED in some scenarios > where a user was previously authenticated against a web app this could > be quietly lost. > Not following you. If you return NOT_ATTEMPTED, other configured auth mechanisms will trigger. If you return NOT_AUTHENTICATED, the flow ends. > Returning NOT_AUTHENTICATED on the other hand forces the challenge phase > again. > No, this does not happen. If NOT_AUTHENTICATED is returned, then no other Auth mechanisms are allowed to challenge. The request ends. > Is caching against the session really the correct approach for your > mechanism? For a number of mechanisms caching against the session is > actually a bad habit carried over from Tomcat, instead alternative > caching should be employed to optimise subsequent authentication token > validation. > I don't follow you. You're saying storing stuff in Servlet.HttpSession is bad why? It bleeds into the user space maybe? JBossWeb (Tomcat too?) has a "session note" feature. Notes are associated with the HttpSession, but not visible to users. They are only visible at the Valve layer. Or are you saying that access tokens should be stored in a cookie? Maybe its not a big deal performance wise in the overall scheme of things, but in my case this would involve validating a RSA256 signature each and every request as well as unmarshalling JSON. I also have refresh tokens as well which I don't want to be stored in a cookie and transmitted with each request. Access tokens are short lived and if somebody gets them, its not as big of a deal as compared to a refresh token which is much longer lived. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From ari.brandeis.king at gmail.com Wed Mar 5 13:45:25 2014 From: ari.brandeis.king at gmail.com (Ari King) Date: Wed, 5 Mar 2014 13:45:25 -0500 Subject: [undertow-dev] Fwd: Help Configuring Handlers In-Reply-To: References: Message-ID: Hi, I'd appreciate help in understanding how to setup handlers. I want paths that begin with "/api" to be handled by JAXRS and all others to be handled by the file resource manager. I'm confused as to why using the defaultContainer works, but using a servlet container factory instance doesn't. When I use the defaultContainer approach, executing a curl GET command against http://localhost:8080/api/example works as expected, however, if I use the servlet container factory, the endpoint is not found. DeploymentManager manager = Servlets.defaultContainer().addDeployment(deployInfo); // But if I switch the container to: // ServletContainer.Factory.newInstance().addDeployment(deployInfo) // and add a path handler: // private final PathHandler pathHandler = new PathHandler(); // pathHandler.addExactPath("/api", manager.start()); // and then set the handler: // .setHandler(pathHandler) // the endpoint(s) aren't found try { server = Undertow.builder() .addHttpListener((int) conf.get("port"), conf.get("host").toString()) .setHandler(manager.start()) .build(); } catch (NumberFormatException | ServletException e) { logger.error("Undertow server build error: {}", e.getMessage()); } Thanks. -Ari -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140305/1c876c2b/attachment.html From sdouglas at redhat.com Wed Mar 5 15:14:44 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Thu, 06 Mar 2014 07:14:44 +1100 Subject: [undertow-dev] Fwd: Help Configuring Handlers In-Reply-To: References: Message-ID: <531785B4.90206@redhat.com> It looks like this issue would be cause by your use of the PathHandler, rather than changing to a new ServletContainer (there should be no real difference between using your own and using the default). In your Servlet deployment are your JAX-RS handlers mapped under /api? If so you are then adding another /api to the path, so the resulting path end up being http://localhost:8080/api/api/example. If you omit the path handler (or register this deployment under '/', if you still want to be able to have other deployments registered under different contexts) then it should work. Stuart Ari King wrote: > Hi, > > I'd appreciate help in understanding how to setup handlers. I want paths > that begin with "/api" to be handled by JAXRS and all others to be > handled by the file resource manager. > > I'm confused as to why using the defaultContainer works, but using a > servlet container factory instance doesn't. When I use the > defaultContainer approach, executing a curl GET command against > http://localhost:8080/api/example works as expected, however, if I use > the servlet container factory, the endpoint is not found. > > DeploymentManager manager = > Servlets.defaultContainer().addDeployment(deployInfo); > > // But if I switch the container to: > // ServletContainer.Factory.newInstance().addDeployment(deployInfo) > // and add a path handler: > // private final PathHandler pathHandler = new PathHandler(); > // pathHandler.addExactPath("/api", manager.start()); > // and then set the handler: > // .setHandler(pathHandler) > // the endpoint(s) aren't found > > try { > server = Undertow.builder() > .addHttpListener((int) conf.get("port"), > conf.get("host").toString()) > .setHandler(manager.start()) > .build(); > } catch (NumberFormatException | ServletException e) { > logger.error("Undertow server build error: {}", e.getMessage()); > } > > > > Thanks. > > -Ari > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From ari.brandeis.king at gmail.com Wed Mar 5 16:47:15 2014 From: ari.brandeis.king at gmail.com (Ari King) Date: Wed, 5 Mar 2014 16:47:15 -0500 Subject: [undertow-dev] Fwd: Help Configuring Handlers In-Reply-To: <531785B4.90206@redhat.com> References: <531785B4.90206@redhat.com> Message-ID: > > It looks like this issue would be cause by your use of the PathHandler, > rather than changing to a new ServletContainer (there should be no real > difference between using your own and using the default). > > In your Servlet deployment are your JAX-RS handlers mapped under /api? > > If so you are then adding another /api to the path, so the resulting path > end up being http://localhost:8080/api/api/example. If you omit the path > handler (or register this deployment under '/', if you still want to be > able to have other deployments registered under different contexts) then it > should work. > > Yes, I registered the deployment under "/api" and assigned the jax-rs application path to have a mapping of "/api" -- I for some reason thought the assignments would overlap, rather than chain. As a follow-up, I do want to set another handler, specifically: setHandler(resource(new FileResourceManager(new File("resources/"), 100)). setDirectoryListingEnabled(true)) Does it matter in which order handlers are set? Is it fine to use a relative path to the "resources" folder which is found under "src/main/"? Or is there another recommended way? Thanks. -Ari -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140305/b4f29a85/attachment.html From ari.brandeis.king at gmail.com Thu Mar 6 11:45:53 2014 From: ari.brandeis.king at gmail.com (Ari King) Date: Thu, 6 Mar 2014 11:45:53 -0500 Subject: [undertow-dev] Help Configuring Handlers Message-ID: > > There can only be one root handler. Basically handlers chain together, so > the current handler picks the next handler (or generates a response). > It sounds like what you want to do is map the JAX-RS handlers to the root > of the servlet deployment, and then use a path handler with the servlet > deployment under /api and the resource handler under /. > Yes, that was exactly what I was intending/attempting to do. Alternatively you just set the Servlet deployment's ResourceManager and > then the resources will just be served up by the DefaultServlet. > >From the docs I know the "ResourceManager" is a built in handler, but is there more information on it or an example of how to set it? Thanks. -Ari -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140306/2e6f8aef/attachment-0001.html From tomaz.cerar at gmail.com Thu Mar 6 12:17:29 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 6 Mar 2014 18:17:29 +0100 Subject: [undertow-dev] Help Configuring Handlers In-Reply-To: References: Message-ID: Something like this: PathHandler root = new PathHandler(); root.addExactPath("/", servlet-root-handler); root.addExactPath("/static-stuff", new ResourceHandler(...)); this way you map your servlet app to / and then override what ever you want below it with resource handler. -- tomaz On Thu, Mar 6, 2014 at 5:45 PM, Ari King wrote: > There can only be one root handler. Basically handlers chain together, so >> the current handler picks the next handler (or generates a response). >> It sounds like what you want to do is map the JAX-RS handlers to the root >> of the servlet deployment, and then use a path handler with the servlet >> deployment under /api and the resource handler under /. >> > > Yes, that was exactly what I was intending/attempting to do. > > Alternatively you just set the Servlet deployment's ResourceManager and >> then the resources will just be served up by the DefaultServlet. >> > > From the docs I know the "ResourceManager" is a built in handler, but is > there more information on it or an example of how to set it? > > Thanks. > > -Ari > > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140306/fcd60181/attachment.html From ari.brandeis.king at gmail.com Fri Mar 7 12:21:44 2014 From: ari.brandeis.king at gmail.com (Ari King) Date: Fri, 7 Mar 2014 12:21:44 -0500 Subject: [undertow-dev] Help Configuring Handlers In-Reply-To: References: Message-ID: > > Something like this: > > PathHandler root = new PathHandler(); > root.addExactPath("/", servlet-root-handler); > root.addExactPath("/static-stuff", new ResourceHandler(...)); > > this way you map your servlet app to / and then override what ever you > want below it with resource handler. > > Don't mean to belabour this seemingly straightforward matter, but I just can't get undertow to work with custom path handler settings. The custom path handler won't serve static files out of "src/main/java/resources/" or recognized the intended jaxrs path of http://localhost:8080/example/1. I've pasted my setup here ; does anyone see what the matter is? Thanks. -Ari -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140307/a524583a/attachment.html From lsgroup at gmail.com Sat Mar 8 16:52:40 2014 From: lsgroup at gmail.com (Lightspoke Discussion) Date: Sat, 8 Mar 2014 13:52:40 -0800 Subject: [undertow-dev] Sharing session attributes in NonBlocking Handlers and Traditional Servlets In-Reply-To: <1827210399.4822231.1392694077935.JavaMail.zimbra@redhat.com> References: <1827210399.4822231.1392694077935.JavaMail.zimbra@redhat.com> Message-ID: Hi Start, Thanks for the response. That makes a lot of sense. I'm having trouble obtaining a non-null ServletRequestContext. I couldn't find another way to obtain a ServletRequestContext. I've included the code I'm using below... public class HelloWorldHandler implements HttpHandler { @Override public void handleRequest(final HttpServerExchange exchange) throws Exception { exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain"); exchange.getResponseSender().send("Hello!"); ServletRequestContext reqctx = exchange.getAttachment(ServletRequestContext.ATTACHMENT_KEY); System.out.println("reqctx="+reqctx); // ... reqctx is null ... Thanks again! On Mon, Feb 17, 2014 at 7:27 PM, Stuart Douglas wrote: > Basically you need to use > io.undertow.servlet.spec.ServletContextImpl#getSession(). > > If your handler is running after the initial servlet handler you can get > this from the io.undertow.servlet.handlers.ServletRequestContext, which is > attached to the exchange. > > If you are running before the initial handler you need to store a > reference to the servlet context or the Deployment somewhere. > > Servlet does not use SessionAttachmentHandler, because each servlet > context can have its own session with its own settings, and multiple > contexts can be involved in the same request if forward/include is used. As > a result each servlet context has its own session manager, and manages it > internally. > > Stuart > > ----- Original Message ----- > > From: "Lightspoke Discussion" > > To: undertow-dev at lists.jboss.org > > Sent: Tuesday, 18 February, 2014 1:08:58 AM > > Subject: [undertow-dev] Sharing session attributes in NonBlocking > Handlers and Traditional Servlets > > > > Hello, > > > > Does anyone know how you might go about sharing session attributes > between a > > servlet and a non-blocking handler in the same project? > > > > InMemorySessionManager sessman = new InMemorySessionManager(foundsessid); > > SessionAttachmentHandler sessattach = new > SessionAttachmentHandler(sessman, > > sessconf); > > SessionManager regsessman = sessattach.getSessionManager(); > > Session session; > > session = sessman.getSession(exchange, sessconf); > > //returns null > > > > > > > > SessionCookieConfig sessconf = new SessionCookieConfig(); > > String foundsessid = sessconf.findSessionId(exchange); > > session = regsessman.getSession(foundsessid); > > System.out.println("getsession by id ="+session ); > > //returns null > > > > > > session = regsessman.createSession(exchange, sessconf); > > System.out.println("create session ="+session ); > > > > //returns a session - but ... > > > > 1. session attributes from servlet do not return its value and > > 2. session attributes across http requests do not persist in memory > > > > Thanks in advance! > > > > > > > > -- > > -- > > Mike > > > > _______________________________________________ > > undertow-dev mailing list > > undertow-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/undertow-dev > -- -- Matthew Ma http://www.lightspoke.com Lightspoke Web Based Database -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140308/7913db66/attachment.html From msnaidu.opensource at gmail.com Sun Mar 9 06:02:06 2014 From: msnaidu.opensource at gmail.com (Naidu Malla) Date: Sun, 9 Mar 2014 15:32:06 +0530 Subject: [undertow-dev] Websocket guide in undertow documentation doesn't contain any information Message-ID: Hi All, Today when i was going though undertow documentation, i found there is no information for websocket guide . http://undertow.io/documentation/core/websockets.html Did anyone notice this? Regards, Naidu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140309/7086c9f1/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: websocket.JPG Type: image/jpeg Size: 63797 bytes Desc: not available Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20140309/7086c9f1/attachment-0001.jpe From msnaidu.opensource at gmail.com Sun Mar 9 06:17:12 2014 From: msnaidu.opensource at gmail.com (Naidu Malla) Date: Sun, 9 Mar 2014 15:47:12 +0530 Subject: [undertow-dev] Websocket guide in undertow documentation doesn't contain any information In-Reply-To: References: Message-ID: Adding some more links which doesn't contain any information in undertow documentation page. http://undertow.io/documentation/core/error-handling.html http://undertow.io/documentation/core/security.html http://undertow.io/documentation/core/reverse-proxy.html http://undertow.io/documentation/core/websockets.html http://undertow.io/documentation/servlet/introduction.html http://undertow.io/documentation/servlet/deployment.html http://undertow.io/documentation/servlet/servlet-extensions.html http://undertow.io/documentation/servlet/advanced-options.html ( This link shows this page itself is not available) Regards, Naidu On Sun, Mar 9, 2014 at 3:32 PM, Naidu Malla wrote: > Hi All, > Today when i was going though undertow documentation, i found there is no > information for websocket guide . > > http://undertow.io/documentation/core/websockets.html > > Did anyone notice this? > > Regards, > Naidu > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140309/54ea205a/attachment.html From sdouglas at redhat.com Sun Mar 9 15:55:43 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 10 Mar 2014 06:55:43 +1100 Subject: [undertow-dev] Sharing session attributes in NonBlocking Handlers and Traditional Servlets In-Reply-To: References: <1827210399.4822231.1392694077935.JavaMail.zimbra@redhat.com> Message-ID: <531CC73F.5050801@redhat.com> This will only be not null after the first servlet handler has run. If your handler is executing outside the scope of the servlet deployment then you need to store a reference to the ServletContext somewhere (worst case = stick it in a static somewhere). Stuart Lightspoke Discussion wrote: > If you are running before the initial handler you need to store a reference to the servlet context or the Deployment somewhere. From sdouglas at redhat.com Sun Mar 9 16:36:55 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 10 Mar 2014 07:36:55 +1100 Subject: [undertow-dev] Help Configuring Handlers In-Reply-To: References: Message-ID: <531CD0E7.7000309@redhat.com> Ari King wrote: > Something like this: > > PathHandler root = new PathHandler(); > root.addExactPath("/", servlet-root-handler); > root.addExactPath("/static-stuff", new ResourceHandler(...)); You need root.addPrefixPath() rather than addExactPath(). addExactPath will only match the exact URL, (so /static-stuff, not /static-stuff/mystuff). Your other problem is that you are not specifying a resource manager for the resource handler (this is probably an issue on my part, it really should required it in the constructor, I will fix). Your new code should look like: root.addPrefixPath("/", servlet-root-handler); root.addPrefixPath("/static-stuff", Handlers.resourceHandler(new ClassPathResourceManager(getClass().getClassLoader(), ""))); ClassPathResourceManager serves up resources from the class path. It takes the class loader to use, and the prefix that you want to serve the resources from (so you can serve from a specific package for instance). Stuart > > this way you map your servlet app to / and then override what ever > you want below it with resource handler. > > > Don't mean to belabour this seemingly straightforward matter, but I > just can't get undertow to work with custom path handler settings. The > custom path handler won't serve static files out of > "src/main/java/resources/" or recognized the intended jaxrs path of > http://localhost:8080/example/1. I've pasted my setup here > ; does anyone see what the matter is? > Thanks. > > -Ari > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From tomaz.cerar at gmail.com Mon Mar 10 06:59:36 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 10 Mar 2014 11:59:36 +0100 Subject: [undertow-dev] Websocket guide in undertow documentation doesn't contain any information In-Reply-To: References: Message-ID: Web page needs some more work, but you ware welcome to contribute if you can. source can be found here https://github.com/undertow-io/undertow-io-site -- tomaz On Sun, Mar 9, 2014 at 11:17 AM, Naidu Malla wrote: > Adding some more links which doesn't contain any information in undertow > documentation page. > > > http://undertow.io/documentation/core/error-handling.html > > > http://undertow.io/documentation/core/security.html > > > http://undertow.io/documentation/core/reverse-proxy.html > > > http://undertow.io/documentation/core/websockets.html > > > http://undertow.io/documentation/servlet/introduction.html > > > http://undertow.io/documentation/servlet/deployment.html > > > http://undertow.io/documentation/servlet/servlet-extensions.html > > > http://undertow.io/documentation/servlet/advanced-options.html ( This > link shows this page itself is not available) > > > > Regards, > > Naidu > > > On Sun, Mar 9, 2014 at 3:32 PM, Naidu Malla wrote: > >> Hi All, >> Today when i was going though undertow documentation, i found there is no >> information for websocket guide . >> >> http://undertow.io/documentation/core/websockets.html >> >> Did anyone notice this? >> >> Regards, >> Naidu >> > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140310/2bbeeda5/attachment.html From jason.greene at redhat.com Mon Mar 10 07:10:26 2014 From: jason.greene at redhat.com (Jason Greene) Date: Mon, 10 Mar 2014 11:10:26 +0000 Subject: [undertow-dev] Websocket guide in undertow documentation doesn't contain any information In-Reply-To: References: Message-ID: We should probably pull the empty sections instead of leaving place holders (IMO) On Mar 10, 2014, at 10:59 AM, Toma? Cerar wrote: > Web page needs some more work, but you ware welcome to contribute if you can. > > source can be found here https://github.com/undertow-io/undertow-io-site > > -- > tomaz > > > On Sun, Mar 9, 2014 at 11:17 AM, Naidu Malla wrote: > Adding some more links which doesn't contain any information in undertow documentation page. > > http://undertow.io/documentation/core/error-handling.html > > http://undertow.io/documentation/core/security.html > > http://undertow.io/documentation/core/reverse-proxy.html > > http://undertow.io/documentation/core/websockets.html > > http://undertow.io/documentation/servlet/introduction.html > > http://undertow.io/documentation/servlet/deployment.html > > http://undertow.io/documentation/servlet/servlet-extensions.html > > http://undertow.io/documentation/servlet/advanced-options.html ( This link shows this page itself is not available) > > > Regards, > Naidu > > > On Sun, Mar 9, 2014 at 3:32 PM, Naidu Malla wrote: > Hi All, > Today when i was going though undertow documentation, i found there is no information for websocket guide . > > http://undertow.io/documentation/core/websockets.html > > Did anyone notice this? > > Regards, > Naidu > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From ccristia at adobe.com Mon Mar 10 07:28:22 2014 From: ccristia at adobe.com (Cristian Constantin) Date: Mon, 10 Mar 2014 11:28:22 +0000 Subject: [undertow-dev] UndertowClient and SSL Message-ID: <9d71d7053d7c4168957c472d8db5302b@BN1PR02MB181.namprd02.prod.outlook.com> Hi, I am using io.undertow.server.handlers.proxy.SimpleProxyClientProvider to implement a Reverse Proxy with Undertow. If I proxy a remote service that uses HTTPS I get the following error: 'java.lang.IllegalArgumentException: UT000065: SSL must be specified to connect to a https URL' at line 61 in HttpClientProvider (I'm using undertow-core-1.0.1.Final). Digging in the sources I found that io.undertow.client.http.HttpClientProvider#connect is called from io.undertow.client.UndertowClient#connect with parameter XnioSsl ssl always null. So is the SSL support for the HTTP client not implemented yet? Or am I missing something here? Regards, Cristian Constantin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140310/fca87bf6/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5502 bytes Desc: not available Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20140310/fca87bf6/attachment.bin From lsgroup at gmail.com Mon Mar 10 15:46:20 2014 From: lsgroup at gmail.com (Lightspoke Discussion) Date: Mon, 10 Mar 2014 12:46:20 -0700 Subject: [undertow-dev] Sharing session attributes in NonBlocking Handlers and Traditional Servlets In-Reply-To: <531CC73F.5050801@redhat.com> References: <1827210399.4822231.1392694077935.JavaMail.zimbra@redhat.com> <531CC73F.5050801@redhat.com> Message-ID: Hi Stuart, I have a regular servlet (the sample... public class HelloWorldServlet extends HttpServlet) running inside the same web context (in the same war). In the HelloWorldServlet I can access the session object. I ran that first, but when I run the non-blocking servlet, my reqctx still returns null. I'm running Wildfly 8.0.0 final, in case that matters. So is everything hinging on: public class ServletInitialHandler implements HttpHandler, ServletDispatcher { ... public void handleRequest(final HttpServerExchange exchange) throws IOException, ServletException ... exchange.putAttachment(ServletRequestContext.ATTACHMENT_KEY, servletRequestContext); ... On Sun, Mar 9, 2014 at 12:55 PM, Stuart Douglas wrote: > This will only be not null after the first servlet handler has run. > If your handler is executing outside the scope of the servlet deployment > then you need to store a reference to the ServletContext somewhere (worst > case = stick it in a static somewhere). > Stuart > > > Lightspoke Discussion wrote: > >> If you are running before the initial handler you need to store a >> reference to the servlet context or the Deployment somewhere. >> > -- -- Matthew Ma http://www.lightspoke.com Lightspoke Web Based Database -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140310/64f3e00c/attachment.html From sdouglas at redhat.com Mon Mar 10 16:37:15 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 11 Mar 2014 07:37:15 +1100 Subject: [undertow-dev] Sharing session attributes in NonBlocking Handlers and Traditional Servlets In-Reply-To: References: <1827210399.4822231.1392694077935.JavaMail.zimbra@redhat.com> <531CC73F.5050801@redhat.com> Message-ID: <531E227B.1040802@redhat.com> Yes, if you are running handlers outside the servlet chain the servlet request context does not get setup. Because you are actually after the ServletContextImpl (which allows you to get the session) you need to get a reference to this at deployment time. How are you setting up your non-blocking handler? Via ServletExtension? If so then the ServletContext is just passed into the extension, so you can just pass it directly to the handler (You will need to cast it to ServletContextImpl though in order to use it to get the session). Stuart Lightspoke Discussion wrote: > Hi Stuart, > > I have a regular servlet (the sample... public class HelloWorldServlet > extends HttpServlet) running inside the same web context (in the same > war). In the HelloWorldServlet I can access the session object. I ran > that first, but when I run the non-blocking servlet, my reqctx still > returns null. > > I'm running Wildfly 8.0.0 final, in case that matters. > > So is everything hinging on: > > > public class ServletInitialHandler implements HttpHandler, > ServletDispatcher { > > ... > publicvoidhandleRequest(finalHttpServerExchangeexchange)throwsIOException,ServletException > ... > > exchange.putAttachment(ServletRequestContext.ATTACHMENT_KEY, > servletRequestContext); > > ... > > > > > > On Sun, Mar 9, 2014 at 12:55 PM, Stuart Douglas > wrote: > > This will only be not null after the first servlet handler has run. > If your handler is executing outside the scope of the servlet > deployment then you need to store a reference to the ServletContext > somewhere (worst case = stick it in a static somewhere). > Stuart > > > Lightspoke Discussion wrote: > > If you are running before the initial handler you need to store > a reference to the servlet context or the Deployment somewhere. > > > > > -- > -- > Matthew Ma > http://www.lightspoke.com > Lightspoke Web Based Database From sdouglas at redhat.com Mon Mar 10 20:49:41 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 11 Mar 2014 11:49:41 +1100 Subject: [undertow-dev] UndertowClient and SSL In-Reply-To: <9d71d7053d7c4168957c472d8db5302b@BN1PR02MB181.namprd02.prod.outlook.com> References: <9d71d7053d7c4168957c472d8db5302b@BN1PR02MB181.namprd02.prod.outlook.com> Message-ID: <531E5DA5.1020906@redhat.com> Oops, this one slipped through the cracks. I will try and get support for this into the next release, however it will require an XNIO API change so it might not make it. I have created this issue: https://issues.jboss.org/browse/UNDERTOW-201 Stuart Cristian Constantin wrote: > Hi, > > I am using io.undertow.server.handlers.proxy.SimpleProxyClientProvider > to implement a Reverse Proxy with Undertow. > > If I proxy a remote service that uses HTTPS I get the following error: > > ?java.lang.IllegalArgumentException: UT000065: SSL must be specified to > connect to a https URL? at line 61 in HttpClientProvider (I?m using > undertow-core-1.0.1.Final). > > Digging in the sources I found that > io.undertow.client.http.HttpClientProvider#connect is called from > io.undertow.client.UndertowClient#connect with parameter XnioSsl ssl > always null. > > So is the SSL support for the HTTP client not implemented yet? Or am I > missing something here? > > Regards, > > Cristian Constantin > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From mpetrov at redhat.com Mon Mar 10 05:21:49 2014 From: mpetrov at redhat.com (Michal Petrov) Date: Mon, 10 Mar 2014 05:21:49 -0400 (EDT) Subject: [undertow-dev] Servlet request and form parameters In-Reply-To: <1415924537.8476856.1394438145238.JavaMail.zimbra@redhat.com> Message-ID: <1182202286.8490406.1394443309820.JavaMail.zimbra@redhat.com> Hi, I'm from the RichFaces team and I've run into a problem with the HttpServletRequestImpl on WildFly 8 Final (Undertow 1.0.1.Final). In our fileUpload component we're intercepting the request and parsing the parts to find the uploaded files, wrapping it and passing it on. Reading the parts sets readStarted to true and so in the Restore View phase when JSF is checking the request parameters they are inaccessible because readStarted stops the parsing of form data. I can work around that but I'm wondering what's the reason for preventing the parsing. Thanks, Michal From sdouglas at redhat.com Mon Mar 10 20:55:01 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 11 Mar 2014 11:55:01 +1100 Subject: [undertow-dev] Servlet request and form parameters In-Reply-To: <1182202286.8490406.1394443309820.JavaMail.zimbra@redhat.com> References: <1182202286.8490406.1394443309820.JavaMail.zimbra@redhat.com> Message-ID: <531E5EE5.5080809@redhat.com> Its how the servlet spec says it should work. Basically if you read the request using the ServletInputStream or the Reader, then the servlet container can't parse data that has already been read. The servlet spec makes it quite clear that you can either read the data yourself, or have the container parse it for you, but not both. Why are you handling multipart yourself anyway, and not just using HttpServletRequest.getParts()? Stuart Michal Petrov wrote: > Hi, > > I'm from the RichFaces team and I've run into a problem with the HttpServletRequestImpl on WildFly 8 Final (Undertow 1.0.1.Final). > > In our fileUpload component we're intercepting the request and parsing the parts to find the uploaded files, wrapping it and passing it on. Reading the parts sets readStarted to true and so in the Restore View phase when JSF is checking the request parameters they are inaccessible because readStarted stops the parsing of form data. I can work around that but I'm wondering what's the reason for preventing the parsing. > > Thanks, > Michal > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From mpetrov at redhat.com Tue Mar 11 05:22:59 2014 From: mpetrov at redhat.com (Michal Petrov) Date: Tue, 11 Mar 2014 05:22:59 -0400 (EDT) Subject: [undertow-dev] Servlet request and form parameters In-Reply-To: <531E5EE5.5080809@redhat.com> References: <1182202286.8490406.1394443309820.JavaMail.zimbra@redhat.com> <531E5EE5.5080809@redhat.com> Message-ID: <2017079125.8838219.1394529779214.JavaMail.zimbra@redhat.com> I'm using getParts() but that prevents access to parameters via getParameter() and the like. Whereas calling getParts() after getParameter() works fine (loadParts() doesn't check if readStarted is true). There was no issue on WildFly 8 CR1 (Undertow 1.0.0.Beta30) but having compared the files, the loadParts() method wasn't changed, so there must've been something else that "pre-parsed" the form data. Michal ----- Original Message ----- From: "Stuart Douglas" To: "Michal Petrov" Cc: undertow-dev at lists.jboss.org Sent: Tuesday, March 11, 2014 1:55:01 AM Subject: Re: [undertow-dev] Servlet request and form parameters Its how the servlet spec says it should work. Basically if you read the request using the ServletInputStream or the Reader, then the servlet container can't parse data that has already been read. The servlet spec makes it quite clear that you can either read the data yourself, or have the container parse it for you, but not both. Why are you handling multipart yourself anyway, and not just using HttpServletRequest.getParts()? Stuart Michal Petrov wrote: > Hi, > > I'm from the RichFaces team and I've run into a problem with the HttpServletRequestImpl on WildFly 8 Final (Undertow 1.0.1.Final). > > In our fileUpload component we're intercepting the request and parsing the parts to find the uploaded files, wrapping it and passing it on. Reading the parts sets readStarted to true and so in the Restore View phase when JSF is checking the request parameters they are inaccessible because readStarted stops the parsing of form data. I can work around that but I'm wondering what's the reason for preventing the parsing. > > Thanks, > Michal > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From bburke at redhat.com Tue Mar 11 10:56:50 2014 From: bburke at redhat.com (Bill Burke) Date: Tue, 11 Mar 2014 10:56:50 -0400 Subject: [undertow-dev] ejb's inheriting security domain Message-ID: <531F2432.80102@redhat.com> Am I wrong stating that EJBs defined in WEB-INF/classes do not inherit the security domain of the servlet container? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From lsgroup at gmail.com Tue Mar 11 13:02:45 2014 From: lsgroup at gmail.com (Lightspoke Discussion) Date: Tue, 11 Mar 2014 10:02:45 -0700 Subject: [undertow-dev] Sharing session attributes in NonBlocking Handlers and Traditional Servlets In-Reply-To: <531E227B.1040802@redhat.com> References: <1827210399.4822231.1392694077935.JavaMail.zimbra@redhat.com> <531CC73F.5050801@redhat.com> <531E227B.1040802@redhat.com> Message-ID: Hi Stuart, It worked! I was able to get the servletcontext and then pass it into the handler as you suggested. Like this: ================================ public class NonBlockingHandlerExtension implements ServletExtension { @Override public void handleDeployment(DeploymentInfo deploymentInfo, ServletContext servletContext) { final ServletContextImpl srvctx = (ServletContextImpl) servletContext; System.out.println("\n\n\n ... \n\n\n srvctx="+srvctx); //returns non-null object deploymentInfo.addInitialHandlerChainWrapper(new HandlerWrapper() { @Override public HttpHandler wrap(final HttpHandler handler) { HelloWorldHandler hwhandler = new HelloWorldHandler(); hwhandler.setServletContext(srvctx); return new PathHandler() .addExactPath("/hello", hwhandler) .addPrefixPath("/", handler); } }); } } then the handler: public class HelloWorldHandler implements HttpHandler { public ServletContextImpl srvctx; public void setServletContext(ServletContextImpl _srvctx) { srvctx = _srvctx; } @Override public void handleRequest(final HttpServerExchange exchange) throws Exception { HttpSessionImpl sessionimpl; sessionimpl = srvctx.getSession(exchange, true); System.out.println("sessionimpl(exchange)="+sessionimpl); System.out.println("1. PRE session get coffee="+sessionimpl.getAttribute("coffee")); sessionimpl.setAttribute("coffee", "Stumptown"); System.out.println("1. POST session get coffee="+sessionimpl.getAttribute("coffee")); ================================ My only concern now is with thread safety and synchronization. Will instantiating a new handler and then passing the servlet context via a public set method be thread safe? Will it introduce any kind of synchronization contention? And is there a "better" way of passing that servlet context into the handler? Also, if it has been there this whole time, how come ServletRequestContext reqctx = exchange.getAttachment(ServletRequestContext.ATTACHMENT_KEY); inside the handleRequest method does not work? Thanks! On Mon, Mar 10, 2014 at 1:37 PM, Stuart Douglas wrote: > Yes, if you are running handlers outside the servlet chain the servlet > request context does not get setup. > > Because you are actually after the ServletContextImpl (which allows you to > get the session) you need to get a reference to this at deployment time. > > How are you setting up your non-blocking handler? Via ServletExtension? > > If so then the ServletContext is just passed into the extension, so you > can just pass it directly to the handler (You will need to cast it to > ServletContextImpl though in order to use it to get the session). > > Stuart > > Lightspoke Discussion wrote: > >> Hi Stuart, >> >> I have a regular servlet (the sample... public class HelloWorldServlet >> extends HttpServlet) running inside the same web context (in the same >> war). In the HelloWorldServlet I can access the session object. I ran >> that first, but when I run the non-blocking servlet, my reqctx still >> returns null. >> >> I'm running Wildfly 8.0.0 final, in case that matters. >> >> So is everything hinging on: >> >> >> public class ServletInitialHandler implements HttpHandler, >> ServletDispatcher { >> >> ... >> publicvoidhandleRequest(finalHttpServerExchangeexchang >> e)throwsIOException,ServletException >> ... >> >> exchange.putAttachment(ServletRequestContext.ATTACHMENT_KEY, >> servletRequestContext); >> >> ... >> >> >> >> >> >> On Sun, Mar 9, 2014 at 12:55 PM, Stuart Douglas > > wrote: >> >> This will only be not null after the first servlet handler has run. >> If your handler is executing outside the scope of the servlet >> deployment then you need to store a reference to the ServletContext >> somewhere (worst case = stick it in a static somewhere). >> Stuart >> >> >> Lightspoke Discussion wrote: >> >> If you are running before the initial handler you need to store >> a reference to the servlet context or the Deployment somewhere. >> >> >> >> >> -- >> -- >> Matthew Ma >> http://www.lightspoke.com >> Lightspoke Web Based Database >> > -- -- Matthew Ma http://www.lightspoke.com Lightspoke Web Based Database -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140311/902e0490/attachment.html From sdouglas at redhat.com Tue Mar 11 17:02:28 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 12 Mar 2014 08:02:28 +1100 Subject: [undertow-dev] Sharing session attributes in NonBlocking Handlers and Traditional Servlets In-Reply-To: References: <1827210399.4822231.1392694077935.JavaMail.zimbra@redhat.com> <531CC73F.5050801@redhat.com> <531E227B.1040802@redhat.com> Message-ID: <531F79E4.7030705@redhat.com> Lightspoke Discussion wrote: > Hi Stuart, > > It worked! I was able to get the servletcontext and then pass it into > the handler as you suggested. Like this: > > ================================ > public class NonBlockingHandlerExtension implements ServletExtension { > @Override > public void handleDeployment(DeploymentInfo deploymentInfo, > ServletContext servletContext) { > final ServletContextImpl srvctx = (ServletContextImpl) > servletContext; > System.out.println("\n\n\n ... \n\n\n srvctx="+srvctx); > //returns non-null object > > deploymentInfo.addInitialHandlerChainWrapper(new HandlerWrapper() { > @Override > public HttpHandler wrap(final HttpHandler handler) { > HelloWorldHandler hwhandler = new HelloWorldHandler(); > hwhandler.setServletContext(srvctx); > return new PathHandler() > .addExactPath("/hello", hwhandler) > .addPrefixPath("/", handler); > } > }); > } > } > > > then the handler: > > public class HelloWorldHandler implements HttpHandler { > public ServletContextImpl srvctx; > public void setServletContext(ServletContextImpl _srvctx) { > srvctx = _srvctx; > } > @Override > public void handleRequest(final HttpServerExchange exchange) throws > Exception { > HttpSessionImpl sessionimpl; > sessionimpl = srvctx.getSession(exchange, true); > System.out.println("sessionimpl(exchange)="+sessionimpl); > System.out.println("1. PRE session get > coffee="+sessionimpl.getAttribute("coffee")); > sessionimpl.setAttribute("coffee", "Stumptown"); > System.out.println("1. POST session get > coffee="+sessionimpl.getAttribute("coffee")); > > > ================================ > > My only concern now is with thread safety and synchronization. > > Will instantiating a new handler and then passing the servlet context > via a public set method be thread safe? Will it introduce any kind of > synchronization contention? Because of the way deployment is done there will be a 'happens before' action when the handler chain is actually registered under the deployment path. So basically it is fine, but in general it is better to use a final field and pass it in the constructor. Stuart > > And is there a "better" way of passing that servlet context into the > handler? > > Also, if it has been there this whole time, how come > > ServletRequestContext reqctx = > exchange.getAttachment(ServletRequestContext.ATTACHMENT_KEY); > > inside the handleRequest method does not work? > > Thanks! > > > > > > > > On Mon, Mar 10, 2014 at 1:37 PM, Stuart Douglas > wrote: > > Yes, if you are running handlers outside the servlet chain the > servlet request context does not get setup. > > Because you are actually after the ServletContextImpl (which allows > you to get the session) you need to get a reference to this at > deployment time. > > How are you setting up your non-blocking handler? Via ServletExtension? > > If so then the ServletContext is just passed into the extension, so > you can just pass it directly to the handler (You will need to cast > it to ServletContextImpl though in order to use it to get the session). > > Stuart > > Lightspoke Discussion wrote: > > Hi Stuart, > > I have a regular servlet (the sample... public class > HelloWorldServlet > extends HttpServlet) running inside the same web context (in the > same > war). In the HelloWorldServlet I can access the session object. > I ran > that first, but when I run the non-blocking servlet, my reqctx still > returns null. > > I'm running Wildfly 8.0.0 final, in case that matters. > > So is everything hinging on: > > > public class ServletInitialHandler implements HttpHandler, > ServletDispatcher { > > ... > publicvoidhandleRequest(__finalHttpServerExchangeexchang__e)throwsIOException,__ServletException > ... > > exchange.putAttachment(__ServletRequestContext.__ATTACHMENT_KEY, > servletRequestContext); > > ... > > > > > > On Sun, Mar 9, 2014 at 12:55 PM, Stuart Douglas > > >> wrote: > > This will only be not null after the first servlet handler > has run. > If your handler is executing outside the scope of the servlet > deployment then you need to store a reference to the > ServletContext > somewhere (worst case = stick it in a static somewhere). > Stuart > > > Lightspoke Discussion wrote: > > If you are running before the initial handler you need > to store > a reference to the servlet context or the Deployment > somewhere. > > > > > -- > -- > Matthew Ma > http://www.lightspoke.com > Lightspoke Web Based Database > > > > > -- > -- > Matthew Ma > http://www.lightspoke.com > Lightspoke Web Based Database From sdouglas at redhat.com Tue Mar 11 18:09:03 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 12 Mar 2014 09:09:03 +1100 Subject: [undertow-dev] Servlet request and form parameters In-Reply-To: <2017079125.8838219.1394529779214.JavaMail.zimbra@redhat.com> References: <1182202286.8490406.1394443309820.JavaMail.zimbra@redhat.com> <531E5EE5.5080809@redhat.com> <2017079125.8838219.1394529779214.JavaMail.zimbra@redhat.com> Message-ID: <531F897F.6090002@redhat.com> Looks like a bug. It should be fixed in Undertow upstream. Stuart Michal Petrov wrote: > I'm using getParts() but that prevents access to parameters via getParameter() and the like. Whereas calling getParts() after getParameter() works fine (loadParts() doesn't check if readStarted is true). There was no issue on WildFly 8 CR1 (Undertow 1.0.0.Beta30) but having compared the files, the loadParts() method wasn't changed, so there must've been something else that "pre-parsed" the form data. > > Michal > > ----- Original Message ----- > From: "Stuart Douglas" > To: "Michal Petrov" > Cc: undertow-dev at lists.jboss.org > Sent: Tuesday, March 11, 2014 1:55:01 AM > Subject: Re: [undertow-dev] Servlet request and form parameters > > Its how the servlet spec says it should work. Basically if you read the > request using the ServletInputStream or the Reader, then the servlet > container can't parse data that has already been read. The servlet spec > makes it quite clear that you can either read the data yourself, or have > the container parse it for you, but not both. > > Why are you handling multipart yourself anyway, and not just using > HttpServletRequest.getParts()? > > Stuart > > > > Michal Petrov wrote: >> Hi, >> >> I'm from the RichFaces team and I've run into a problem with the HttpServletRequestImpl on WildFly 8 Final (Undertow 1.0.1.Final). >> >> In our fileUpload component we're intercepting the request and parsing the parts to find the uploaded files, wrapping it and passing it on. Reading the parts sets readStarted to true and so in the Restore View phase when JSF is checking the request parameters they are inaccessible because readStarted stops the parsing of form data. I can work around that but I'm wondering what's the reason for preventing the parsing. >> >> Thanks, >> Michal >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev From sdouglas at redhat.com Wed Mar 12 00:52:59 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 12 Mar 2014 15:52:59 +1100 Subject: [undertow-dev] ejb's inheriting security domain In-Reply-To: <531F2432.80102@redhat.com> References: <531F2432.80102@redhat.com> Message-ID: <531FE82B.9080906@redhat.com> They don't, it has to be explicitly specified either via annotations or via the jboss-ejb3.xml file. This does not actually have anything to do with Undertow, this is all part of the Wildfly code base. Stuart Bill Burke wrote: > Am I wrong stating that EJBs defined in WEB-INF/classes do not inherit > the security domain of the servlet container? > From bburke at redhat.com Wed Mar 12 09:11:43 2014 From: bburke at redhat.com (Bill Burke) Date: Wed, 12 Mar 2014 09:11:43 -0400 Subject: [undertow-dev] ejb's inheriting security domain In-Reply-To: <531FE82B.9080906@redhat.com> References: <531F2432.80102@redhat.com> <531FE82B.9080906@redhat.com> Message-ID: <53205D0F.3010502@redhat.com> Do you think they should inherit the domain? Just curious on your thoughts. On 3/12/2014 12:52 AM, Stuart Douglas wrote: > They don't, it has to be explicitly specified either via annotations or > via the jboss-ejb3.xml file. > > This does not actually have anything to do with Undertow, this is all > part of the Wildfly code base. > > Stuart > > Bill Burke wrote: >> Am I wrong stating that EJBs defined in WEB-INF/classes do not inherit >> the security domain of the servlet container? >> -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com