Hi,
On Mon, May 19, 2014 at 11:03 PM, Marco Springer <[email protected]> wrote: > Hi all, > > I'm trying to get something working that should be fairly easy, I think. > > I have Nginx sitting in-front of Jetty. > An incoming URL could be: http://rage.glitchbox.nl/param1 > The proxy should proxy this to: http://localhost:8080/app/param1 > The webapplication is deployed as root application and is the only > application > You say it is deployed as root app and below we see that WicketFilter listens on /*. So what is /app in this case ?! > in that Jetty instance (or Tomcat if that would've been used) > The wicket mount: > mountPage("/app/${param}", AppPage.class); (the "param1" is a dynamic > value) > > The actual generated HTML is fine. > No images are loaded, no JS, nor any wicket resource. > I've traced this back as to probably being a resource mapping or nginx > config > problem, but I'd love some confirmation on this. > The generated HTML points to the resources as: > "../../wicket/resource/etc...." > Due to the proxy setting, nginx sets this to: > "/app/wicket/resource/etc......". > Do I need to adjust the nginx configuration to filter on "/wicket/" and > sent > those requests through directly? Or do I need to do something about how > wicket > generates the paths for it's requests? No sure how to continue here. > Requests to /wicket/** should be no different to the other requests. But if you want to change the values of these special segments then see Application#newMapperContext. This won't help you much IMO. > > Also, some pages need authentication before they can be accessed, I'm using > the wicket auth-roles package for this. But when that's being used, > something > weird is going on.. > If I request a page that needs authentication it does redirect me to the > proper login page, that's fine (doesn't load the resources, images/css, > though). > Upon succesful login the browser is redirected to > "localhost:8080/app/privilegedpage", instead of > "http://rage.glitchbox.nl/privilegedpage";. Which I find very strange, is > this > also something in nginx that's wrong or wicket behavior? > it looks to me like not finished *reverse* proxy config. Wicket generates only relative urls and will not generate http://someHost/unless you explicitly ask for a full url. > This login requirement is enforced through this code, which is in a > AuthenticatedWebPage implementation: > @Override > protected void onConfigure() { > AuthenticatedWebApplication app = (AuthenticatedWebApplication) > Application.get(); > > if(!AuthenticatedWebSession.get().isSignedIn()) { > app.restartResponseAtSignInPage(); > } > } > > The SignInPage is the default SignInPage in the authroles package. > > I've googled around quite a bit for fellow nginx/wicket users. But to no > real > avail of a solution. > Examples: > > http://www.mysticcoders.com/blog/how-to-setup-a-wicket-application-with-nginx-and-jetty/(where > I've taken my first attempt from and still seems to give the > best result) > I've also taken a look at: > > https://cwiki.apache.org/confluence/display/WICKET/Wicket+and+localized+URLs > & > http://blog.jteam.nl/2010/02/24/wicket-root-mounts/ > This for making "http://localhost:8080/app/param1"; into > "http://localhost:8080/param1";, for the dynamic root mounts but seemed > like a > lot of hassle for something relatively easy, an http proxy in-front of > jetty. > > If anyone can point me into the right direction, that would be great. > > The Nginx reverse proxy mapping: > location / { > proxy_pass http://localhost:8080/app/; > proxy_pass_header Set-Cookie; > proxy_pass_header X-Forwarded-For; > proxy_set_header X-Real-IP $remote_addr; > proxy_pass_header Host; > } > > Wicket web.xml: > (only thing noteworthy, as Im not sure this correct?) > <filter-mapping> > <filter-name>applicationname</filter-name> > <url-pattern>/*</url-pattern> > I think this should be /app/* > </filter-mapping> > > I'm using the WicketFilter, not the WicketServlet approach. > > If required, I'll whip up some quickstart tomorrow, not enough time for > that > now. > If you don't manage to setup it then please create a quickstart together with nginx conf. > > Thanks in advance. > > Cheers, > Marco Springer > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
