Re: Frustrating behavior ... same browser, same war, same tomcat version - different behavior!!!
I haven't got to the bottom of it exactly, but it's related to our (my) attempt to integrate jcifs and ntml SSO in to the application. It's gone back now to our main software vendor to figure out from here. Bryan. On Tue, Jun 8, 2010 at 8:46 AM, Bryan Montgomery mo...@english.net wrote: Thanks for all the ideas and interest - I still haven't solved it. It did seem to work for a while but then as I changed a configuration to prove what was broken - I haven't been able to get it working again. I'm thinking it is some sort of caching issue - but I can't find any settings, tomcat is running as root so it shouldn't be any permission issues .. I need to move on with the project so I am probably just going to get a new virtual server built. I want to keep the old around because it is bugging the heck out of me :) On Tue, Jun 8, 2010 at 6:58 AM, nino martinez wael nino.martinez.w...@gmail.com wrote: did you solve this yet? 2010/6/7 Bryan Montgomery mo...@english.net: Thanks - this is still puzzling me. This is a virtual machine. I did just try the war on another virtual machine and it worked as expected. I think I'm about to rebuild the server. I don't have any clustering, and not using apache, just hitting tomcat directly. One thing I noticed from the profiling on IE8 is that on the servers that worked normally, the postbacks had the jsessionid appended to the url. The non-working server is missing that so I'm doing a little bit of digging to see if I can find a reason why that may be happening. Cheers - Bryan. On Fri, Jun 4, 2010 at 7:33 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: right, sounds like the session is being lost and the page is being rerendered fresh. -igor On Fri, Jun 4, 2010 at 1:46 PM, Scott Swank scott.sw...@gmail.com wrote: Do you have apache or a load balancer or anything else in the network? Is there maybe a simple difference in your httpd.conf pertaining to sessions? On Fri, Jun 4, 2010 at 1:32 PM, Bryan Montgomery mo...@english.net wrote: Thanks for the ideas. Still no joy. The behavior is consistent between three different clients, all running different versions of IE (6,7 and 8). I was able to use the debugging feature built in to IE 8 to see that the wicket ajax javascript was gettting called. At some point in that process it lost the value of the field and it got set to an empty field. I have the feeling that there is something different with the environment on this particular server - but I have no idea what at this point. On Fri, Jun 4, 2010 at 1:32 PM, gnul nullc...@gmail.com wrote: Essentially, part of the process generates dynamic web forms based on xml configuration files. We noticed that on one of our servers when we deployed the war file that the fields would not hold their values, and as soon as you tabbed out, the entry would disappear. Taking the same war file and deploying it to another server the form acts as expected. If it works on one server, but not the other, and they are configured the same (meaning same appserver/tomcat version, same jvm, same user/group/perms, etc.), the first thing I do is clean the appserver and do a fresh deploy. For example, say you are deploying to /var/lib/tomcat/webapps/, I would shutdown both tomcats, remove the exploded directories (e.g. myapp.war = myapp/ ) and re-deploy the war files to each server. I would also clean out tomcat's temp directory (e.g. /var/cache/tomcat5/temp), then restart them both. -gnul - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Frustrating behavior ... same browser, same war, same tomcat version - different behavior!!!
Thanks for all the ideas and interest - I still haven't solved it. It did seem to work for a while but then as I changed a configuration to prove what was broken - I haven't been able to get it working again. I'm thinking it is some sort of caching issue - but I can't find any settings, tomcat is running as root so it shouldn't be any permission issues .. I need to move on with the project so I am probably just going to get a new virtual server built. I want to keep the old around because it is bugging the heck out of me :) On Tue, Jun 8, 2010 at 6:58 AM, nino martinez wael nino.martinez.w...@gmail.com wrote: did you solve this yet? 2010/6/7 Bryan Montgomery mo...@english.net: Thanks - this is still puzzling me. This is a virtual machine. I did just try the war on another virtual machine and it worked as expected. I think I'm about to rebuild the server. I don't have any clustering, and not using apache, just hitting tomcat directly. One thing I noticed from the profiling on IE8 is that on the servers that worked normally, the postbacks had the jsessionid appended to the url. The non-working server is missing that so I'm doing a little bit of digging to see if I can find a reason why that may be happening. Cheers - Bryan. On Fri, Jun 4, 2010 at 7:33 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: right, sounds like the session is being lost and the page is being rerendered fresh. -igor On Fri, Jun 4, 2010 at 1:46 PM, Scott Swank scott.sw...@gmail.com wrote: Do you have apache or a load balancer or anything else in the network? Is there maybe a simple difference in your httpd.conf pertaining to sessions? On Fri, Jun 4, 2010 at 1:32 PM, Bryan Montgomery mo...@english.net wrote: Thanks for the ideas. Still no joy. The behavior is consistent between three different clients, all running different versions of IE (6,7 and 8). I was able to use the debugging feature built in to IE 8 to see that the wicket ajax javascript was gettting called. At some point in that process it lost the value of the field and it got set to an empty field. I have the feeling that there is something different with the environment on this particular server - but I have no idea what at this point. On Fri, Jun 4, 2010 at 1:32 PM, gnul nullc...@gmail.com wrote: Essentially, part of the process generates dynamic web forms based on xml configuration files. We noticed that on one of our servers when we deployed the war file that the fields would not hold their values, and as soon as you tabbed out, the entry would disappear. Taking the same war file and deploying it to another server the form acts as expected. If it works on one server, but not the other, and they are configured the same (meaning same appserver/tomcat version, same jvm, same user/group/perms, etc.), the first thing I do is clean the appserver and do a fresh deploy. For example, say you are deploying to /var/lib/tomcat/webapps/, I would shutdown both tomcats, remove the exploded directories (e.g. myapp.war = myapp/ ) and re-deploy the war files to each server. I would also clean out tomcat's temp directory (e.g. /var/cache/tomcat5/temp), then restart them both. -gnul - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Frustrating behavior ... same browser, same war, same tomcat version - different behavior!!!
Thanks - this is still puzzling me. This is a virtual machine. I did just try the war on another virtual machine and it worked as expected. I think I'm about to rebuild the server. I don't have any clustering, and not using apache, just hitting tomcat directly. One thing I noticed from the profiling on IE8 is that on the servers that worked normally, the postbacks had the jsessionid appended to the url. The non-working server is missing that so I'm doing a little bit of digging to see if I can find a reason why that may be happening. Cheers - Bryan. On Fri, Jun 4, 2010 at 7:33 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: right, sounds like the session is being lost and the page is being rerendered fresh. -igor On Fri, Jun 4, 2010 at 1:46 PM, Scott Swank scott.sw...@gmail.com wrote: Do you have apache or a load balancer or anything else in the network? Is there maybe a simple difference in your httpd.conf pertaining to sessions? On Fri, Jun 4, 2010 at 1:32 PM, Bryan Montgomery mo...@english.net wrote: Thanks for the ideas. Still no joy. The behavior is consistent between three different clients, all running different versions of IE (6,7 and 8). I was able to use the debugging feature built in to IE 8 to see that the wicket ajax javascript was gettting called. At some point in that process it lost the value of the field and it got set to an empty field. I have the feeling that there is something different with the environment on this particular server - but I have no idea what at this point. On Fri, Jun 4, 2010 at 1:32 PM, gnul nullc...@gmail.com wrote: Essentially, part of the process generates dynamic web forms based on xml configuration files. We noticed that on one of our servers when we deployed the war file that the fields would not hold their values, and as soon as you tabbed out, the entry would disappear. Taking the same war file and deploying it to another server the form acts as expected. If it works on one server, but not the other, and they are configured the same (meaning same appserver/tomcat version, same jvm, same user/group/perms, etc.), the first thing I do is clean the appserver and do a fresh deploy. For example, say you are deploying to /var/lib/tomcat/webapps/, I would shutdown both tomcats, remove the exploded directories (e.g. myapp.war = myapp/ ) and re-deploy the war files to each server. I would also clean out tomcat's temp directory (e.g. /var/cache/tomcat5/temp), then restart them both. -gnul - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Frustrating behavior ... same browser, same war, same tomcat version - different behavior!!!
Hello,
I've been banging my head against the proverbial brick wall for the last
day. I have a fairly large web application which I've been modifying part
of.
Essentially, part of the process generates dynamic web forms based on xml
configuration files. We noticed that on one of our servers when we deployed
the war file that the fields would not hold their values, and as soon as you
tabbed out, the entry would disappear. Taking the same war file and
deploying it to another server the form acts as expected.
This has been tried on both ie 7 and ie 8 with the same results.
Looking at the html on the browser, it is pretty simple. If I save the file
to the local machine and replace the relative links with absolute links I
can't reproduce the errors - although I do get javascript errors. Comparing
the html between the working server and the problematic server, the only
difference is wicket field references.
Comparing the javascript files and ccs files, they are identical. I'm
guessing it has something to do with the onblur in the html below - but why
would it exhibt a different behavior between the servers? I'm not sure why
we're using ajax there as the page doesn't have any ajax / callback features
to it as far as I know.
Is there some other tomcat setting that could be effecting this? Somewhere
else I should look?
Thanks,
Bryan.
html xmlns='http://www.w3.org/1999/xhtml' lang='en'
headlink rel=stylesheet type=text/css
href=../../../../resources/com.abc.reports.page.MainPage/style/nrgWeb.css
view-source:http://coned-avl:8080/nrg/app/resources/com.samsix.reports.page.MainPage/style/nrgWeb.css
/
link type='image/x-icon' rel='icon'
href='../../../../../favicon_oru.ico
view-source:http://coned-avl:8080/nrg/favicon_oru.ico' /
link type='image/x-icon' rel='shortcut icon'
href='../../../../../favicon_oru.ico
view-source:http://coned-avl:8080/nrg/favicon_oru.ico' /
script type=text/javascript
src=../../../../resources/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js
view-source:http://coned-avl:8080/nrg/app/resources/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js/script
script type=text/javascript
src=../../../../resources/org.apache.wicket.ajax.WicketAjaxReference/wicket-ajax.js
view-source:http://coned-avl:8080/nrg/app/resources/org.apache.wicket.ajax.WicketAjaxReference/wicket-ajax.js/script
/headbody topmargin='0'
titleAnalysis/title
span class='pageTitle'Single Analysis/span
span
a href=../../../../startup
view-source:http://coned-avl:8080/nrg/app/startup
span
img
src=../../../../resources/org.apache.wicket.Application/back_button
view-source:http://coned-avl:8080/nrg/app/resources/org.apache.wicket.Application/back_button
border=0/
/span
/a
/span
br /
h1 class='reportMenu'Analysis/h1
h1 class='reportDescription'Single pass analysis./h1
span
/span
form id=queryForm7 method=post
action=../../../../?wicket:interface=:7:queryForm::IFormSubmitListener::div
style=display:noneinput type=hidden name=queryForm7_hf_0
id=queryForm7_hf_0 //div
table
tr
td
span class=labelCircuit/span
/td
td
input type=text value= name=circuitField
id=circuitField8 onblur=var
wcall=wicketAjaxPost('../../../../?wicket:interface=:7:queryForm:circuitField::IBehaviorListener:0:4',
wicketSerialize(Wicket.$('circuitField8')),null,null, function()
{return Wicket.$('circuitField8') != null;}.bind(this));/
/td
/tr
tr
td
span class=labelSegment/span
/td
td
input type=text value= name=segmentField
id=segmentField9 onblur=var
wcall=wicketAjaxPost('../../../../?wicket:interface=:7:queryForm:segmentField::IBehaviorListener:0:4',
wicketSerialize(Wicket.$('segmentField9')),null,null, function()
{return Wicket.$('segmentField9') != null;}.bind(this));/
/td
/tr
tr
td/td
td align='right'
input type='submit' name='submit' value='Execute Query' /
/td
/tr
/table
/form
/body
/html
Re: Frustrating behavior ... same browser, same war, same tomcat version - different behavior!!!
Yeah, I thought it might be as simple as that - but unfortunately not.
On Fri, Jun 4, 2010 at 12:29 PM, James Carman ja...@carmanconsulting.comwrote:
Have you tried clearing your cache on your browsers?
On Fri, Jun 4, 2010 at 11:57 AM, Bryan Montgomery mo...@english.net
wrote:
Hello,
I've been banging my head against the proverbial brick wall for the last
day. I have a fairly large web application which I've been modifying part
of.
Essentially, part of the process generates dynamic web forms based on xml
configuration files. We noticed that on one of our servers when we
deployed
the war file that the fields would not hold their values, and as soon as
you
tabbed out, the entry would disappear. Taking the same war file and
deploying it to another server the form acts as expected.
This has been tried on both ie 7 and ie 8 with the same results.
Looking at the html on the browser, it is pretty simple. If I save the
file
to the local machine and replace the relative links with absolute links I
can't reproduce the errors - although I do get javascript errors.
Comparing
the html between the working server and the problematic server, the only
difference is wicket field references.
Comparing the javascript files and ccs files, they are identical. I'm
guessing it has something to do with the onblur in the html below - but
why
would it exhibt a different behavior between the servers? I'm not sure
why
we're using ajax there as the page doesn't have any ajax / callback
features
to it as far as I know.
Is there some other tomcat setting that could be effecting this?
Somewhere
else I should look?
Thanks,
Bryan.
html xmlns='http://www.w3.org/1999/xhtml' lang='en'
headlink rel=stylesheet type=text/css
href=../../../../resources/com.abc.reports.page.MainPage/style/nrgWeb.css
view-source:
http://coned-avl:8080/nrg/app/resources/com.samsix.reports.page.MainPage/style/nrgWeb.css
/
link type='image/x-icon' rel='icon'
href='../../../../../favicon_oru.ico
view-source:http://coned-avl:8080/nrg/favicon_oru.ico' /
link type='image/x-icon' rel='shortcut icon'
href='../../../../../favicon_oru.ico
view-source:http://coned-avl:8080/nrg/favicon_oru.ico' /
script type=text/javascript
src=../../../../resources/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js
view-source:
http://coned-avl:8080/nrg/app/resources/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js
/script
script type=text/javascript
src=../../../../resources/org.apache.wicket.ajax.WicketAjaxReference/wicket-ajax.js
view-source:
http://coned-avl:8080/nrg/app/resources/org.apache.wicket.ajax.WicketAjaxReference/wicket-ajax.js
/script
/headbody topmargin='0'
titleAnalysis/title
span class='pageTitle'Single Analysis/span
span
a href=../../../../startup
view-source:http://coned-avl:8080/nrg/app/startup
span
img
src=../../../../resources/org.apache.wicket.Application/back_button
view-source:
http://coned-avl:8080/nrg/app/resources/org.apache.wicket.Application/back_button
border=0/
/span
/a
/span
br /
h1 class='reportMenu'Analysis/h1
h1 class='reportDescription'Single pass analysis./h1
span
/span
form id=queryForm7 method=post
action=../../../../?wicket:interface=:7:queryForm::IFormSubmitListener::div
style=display:noneinput type=hidden name=queryForm7_hf_0
id=queryForm7_hf_0 //div
table
tr
td
span class=labelCircuit/span
/td
td
input type=text value= name=circuitField
id=circuitField8 onblur=var
wcall=wicketAjaxPost('../../../../?wicket:interface=:7:queryForm:circuitField::IBehaviorListener:0:4',
wicketSerialize(Wicket.$('circuitField8')),null,null, function()
{return Wicket.$('circuitField8') != null;}.bind(this));/
/td
/tr
tr
td
span class=labelSegment/span
/td
td
input type=text value= name=segmentField
id=segmentField9 onblur=var
wcall=wicketAjaxPost('../../../../?wicket:interface=:7:queryForm:segmentField::IBehaviorListener:0:4',
wicketSerialize(Wicket.$('segmentField9')),null,null, function()
{return Wicket.$('segmentField9') != null;}.bind(this));/
/td
/tr
tr
td/td
td align='right'
input type='submit' name='submit' value='Execute Query' /
/td
/tr
/table
/form
/body
/html
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Frustrating behavior ... same browser, same war, same tomcat version - different behavior!!!
Thanks for the ideas. Still no joy. The behavior is consistent between three different clients, all running different versions of IE (6,7 and 8). I was able to use the debugging feature built in to IE 8 to see that the wicket ajax javascript was gettting called. At some point in that process it lost the value of the field and it got set to an empty field. I have the feeling that there is something different with the environment on this particular server - but I have no idea what at this point. On Fri, Jun 4, 2010 at 1:32 PM, gnul nullc...@gmail.com wrote: Essentially, part of the process generates dynamic web forms based on xml configuration files. We noticed that on one of our servers when we deployed the war file that the fields would not hold their values, and as soon as you tabbed out, the entry would disappear. Taking the same war file and deploying it to another server the form acts as expected. If it works on one server, but not the other, and they are configured the same (meaning same appserver/tomcat version, same jvm, same user/group/perms, etc.), the first thing I do is clean the appserver and do a fresh deploy. For example, say you are deploying to /var/lib/tomcat/webapps/, I would shutdown both tomcats, remove the exploded directories (e.g. myapp.war = myapp/ ) and re-deploy the war files to each server. I would also clean out tomcat's temp directory (e.g. /var/cache/tomcat5/temp), then restart them both. -gnul - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket form data isn't received
Hello, I left this for a week - but had another look. It's weird - if I don't mess with the flow (ie don;t try to do NTLM authentication) it works fine. However, I somehow seem to be messing up the process flow with the NTLM authentication. Unfortunately I'm not currently running through an ide so I'm relying on debug statements. don't know if it will shed any light, but what I'm seeing is; Make request to /app (redirects to login page which includes login panel) In LoginPage - constructor, username password null In LoginPanel constructor In LoginPanel.onBeforeRender Call ntlm authorization throw AbortWithHttpStatusException In LoginPage - constructor, username password null In LoginPanel constructor In LoginPanel.onBeforeRender At this point, have an authentication header, but no user information. In LoginPage - constructor, username password null In LoginPanel constructor In LoginPanel.onBeforeRender Obtain and validate ntlm authentication Call AuthenticatedWebSession.get().signIn with windows username throw unknown user exception catch exception, call error Page displayed to user - fill in form, hit submit In LoginPanel.onBeforeRender (no constructor called) user is empty string (not value entered or null) At this point I get the entry below, so it seems that the submit isnot getting called and also that the user and passwod values are not being submitted from the form to the class. 05 Apr 2010 09:55:24,798: time=25,event=Interface[target:NrgLoginPanel$OmsLoginForm(nrgLoginPanel:loginForm), page: com.sam.auth.NrgLoginPage(2), interface: IFormSubmitListener.onFormSubmitted],response=Interface[target:NrgLoginPanel$OmsLoginForm(nrgLoginPanel:loginForm), page: com.sam.auth.NrgLoginPage(2), interface: IFormSubmitListener.onFormSubmitted],sessionid=564654FE9A6195261CB9895783FCDD45,sessionsize=6970,sessionstart=Mon Apr 05 09:55:13 EDT 2010,requests=6,totaltime=2612,activerequests=0,maxmem=891M,total=531M,used=261M On Fri, Mar 26, 2010 at 5:14 PM, Josh Chappelle jchappe...@4redi.comwrote: Bryan, Have you put a breakpoint in your onSubmit method of the form to see if it is getting to that point? If it isn't then make sure you don't have a validator failing and no feedback panel. I've made that mistake before. Thanks, Josh -Original Message- From: Bryan Montgomery [mailto:mo...@english.net] Sent: Friday, March 26, 2010 3:33 PM To: users@wicket.apache.org Subject: Wicket form data isn't received I've been working on an existing wicket application and am banging my head against the desk :) I'm trying to have two different pages that handle the sign on for the authenticated web session. One which is using ntlm with jcifs works fine. However, I can't get any other forms to work. I see from looking closely at the log file that the data is posted - however it almost looks like it's redirected. I did see that it was 'unable to find cookie' - but i wouldn't think that is the problem. I've looked through the web.xml and the page we have that extends the AuthenticatedWebApplication. I'm not sure if that is the issue, or if it something else. I wonder if the form is being redirected as it is not authenticated ending up in a catch 22. Is a way to have unauthenticated pages when using the AuthenticatedWebApplication? Or am I stuck in a vicious circle :) I've included the html and java, based on the article at http://www.developer.com/java/web/article.php/3673576/Wicket-The-First-Steps .htmhttp://www.developer.com/java/web/article.php/3673576/Wicket-The-First-Steps%0A.htm 26 Mar 2010 13:42:13,430: (request cycle) url: /nrg/app/test 26 Mar 2010 13:42:13,603: Add userId to [MarkupContainer [Component id = loginForm]] 26 Mar 2010 13:42:13,605: Add loginForm to [Page class = com.sam.auth.TestLogin, id = 0, version = 0] 26 Mar 2010 13:42:13,649: Begin render [Page class = com.sam.auth.TestLogin, id = 0, version = 0] 26 Mar 2010 13:42:13,657: Load markup: cacheKey=com.sam.auth.TestLoginen_UShtml 26 Mar 2010 13:42:13,694: Loading markup from file:/home/HOMEDIRS/montgomeryb/tomcat/webapps/nrg/WEB-INF/classes/com/sam/a uth/TestLogin.html 26 Mar 2010 13:42:13,756: ending request for page [Page class = com.sam.auth.TestLogin, id = 0, version = 0], request [method = GET, protocol = HTTP/1.1, requestURL = http://poe3b:8800/nrg/app/test, contentType = null, contentLength = -1, contextPath = /nrg, pathInfo = null, requestURI = /nrg/app/test, servletPath = /app/test, pathTranslated = null] 26 Mar 2010 13:42:13,771: time=328,event=BookmarkablePage[com.sam.auth.TestLogin()],response=Bookmarka blePage[com.sam.auth.TestLogin()],sessionid=535C7A65C8E2F12DE0EEA8EF26830D80 ,sessionsize=326,sessionstart=Fri Mar 26 13:42:13 EDT 2010,requests=2,totaltime=328,activerequests=0,maxmem=891M,total=525M,used=2 45M 26 Mar 2010 13:42:13,771: ending request for page [Page class = com.sam.auth.TestLogin, id = 0, version = 0], request [method = GET, protocol = HTTP
Wicket form data isn't received
I've been working on an existing wicket application and am banging my head against the desk :) I'm trying to have two different pages that handle the sign on for the authenticated web session. One which is using ntlm with jcifs works fine. However, I can't get any other forms to work. I see from looking closely at the log file that the data is posted - however it almost looks like it's redirected. I did see that it was 'unable to find cookie' - but i wouldn't think that is the problem. I've looked through the web.xml and the page we have that extends the AuthenticatedWebApplication. I'm not sure if that is the issue, or if it something else. I wonder if the form is being redirected as it is not authenticated ending up in a catch 22. Is a way to have unauthenticated pages when using the AuthenticatedWebApplication? Or am I stuck in a vicious circle :) I've included the html and java, based on the article at http://www.developer.com/java/web/article.php/3673576/Wicket-The-First-Steps.htm 26 Mar 2010 13:42:13,430: (request cycle) url: /nrg/app/test 26 Mar 2010 13:42:13,603: Add userId to [MarkupContainer [Component id = loginForm]] 26 Mar 2010 13:42:13,605: Add loginForm to [Page class = com.sam.auth.TestLogin, id = 0, version = 0] 26 Mar 2010 13:42:13,649: Begin render [Page class = com.sam.auth.TestLogin, id = 0, version = 0] 26 Mar 2010 13:42:13,657: Load markup: cacheKey=com.sam.auth.TestLoginen_UShtml 26 Mar 2010 13:42:13,694: Loading markup from file:/home/HOMEDIRS/montgomeryb/tomcat/webapps/nrg/WEB-INF/classes/com/sam/auth/TestLogin.html 26 Mar 2010 13:42:13,756: ending request for page [Page class = com.sam.auth.TestLogin, id = 0, version = 0], request [method = GET, protocol = HTTP/1.1, requestURL = http://poe3b:8800/nrg/app/test, contentType = null, contentLength = -1, contextPath = /nrg, pathInfo = null, requestURI = /nrg/app/test, servletPath = /app/test, pathTranslated = null] 26 Mar 2010 13:42:13,771: time=328,event=BookmarkablePage[com.sam.auth.TestLogin()],response=BookmarkablePage[com.sam.auth.TestLogin()],sessionid=535C7A65C8E2F12DE0EEA8EF26830D80,sessionsize=326,sessionstart=Fri Mar 26 13:42:13 EDT 2010,requests=2,totaltime=328,activerequests=0,maxmem=891M,total=525M,used=245M 26 Mar 2010 13:42:13,771: ending request for page [Page class = com.sam.auth.TestLogin, id = 0, version = 0], request [method = GET, protocol = HTTP/1.1, requestURL = http://poe3b:8800/nrg/app/test, contentType = null, contentLength = -1, contextPath = /nrg, pathInfo = null, requestURI = /nrg/app/test, servletPath = /app/test, pathTranslated = null] 26 Mar 2010 13:42:18,771: (request cycle) url: /nrg/app/test 26 Mar 2010 13:42:18,772: Getting page [path = 0:loginForm, versionNumber = 0] 26 Mar 2010 13:42:18,774: registered listener interface [RequestListenerInterface name=INewBrowserWindowListener, method=public abstract void org.apache.wicket.markup.html.INewBrowserWindowListener.onNewBrowserWindow()] 26 Mar 2010 13:42:18,790: Unable to find Cookie with name=loginForm.userId and request URI=/nrg/app/test You entered User id null 26 Mar 2010 13:42:18,793: Begin render [Page class = com.sam.auth.TestLogin, id = 0, version = 0] 26 Mar 2010 13:42:18,799: Rendering raw markup 26 Mar 2010 13:42:18,807: End render [Page class = com.sam.auth.TestLogin, id = 0, version = 0] 26 Mar 2010 13:42:18,809: ending request for page [Page class = com.sam.auth.TestLogin, id = 0, version = 0], request [method = POST, protocol = HTTP/1.1, requestURL = http://poe3b:8800/nrg/app/test, contentType = application/x-www-form-urlencoded, contentLength = 0, contextPath = /nrg, pathInfo = null, requestURI = /nrg/app/test, servletPath = /app/test, pathTranslated = null] 26 Mar 2010 13:42:18,813: time=38,event=Interface[target:TestLogin$LoginForm(loginForm), page: com.sam.auth.TestLogin(0), interface: IFormSubmitListener.onFormSubmitted],response=Interface[target:TestLogin$LoginForm(loginForm), page: com.sam.auth.TestLogin(0), interface: IFormSubmitListener.onFormSubmitted],sessionid=535C7A65C8E2F12DE0EEA8EF26830D80,sessionsize=2602,sessionstart=Fri Mar 26 13:42:13 EDT 2010,requests=3,totaltime=366,activerequests=0,maxmem=891M,total=525M,used=253M 26 Mar 2010 13:42:18,815: ending request for page [Page class = com.sam.auth.TestLogin, id = 0, version = 0], request [method = POST, protocol = HTTP/1.1, requestURL = http://poe3b:8800/nrg/app/test, contentType = application/x-www-form-urlencoded, contentLength = 0, contextPath = /nrg, pathInfo = null, requestURI = /nrg/app/test, servletPath = /app/test, pathTranslated = null] 26 Mar 2010 13:42:18,816: Redirecting to ?wicket:interface=:0 html titleHello World/title body form wicket:id=loginForm User Name input type=text wicket:id=userId/br/ input type=submit value=Login/ /form /body /html package com.sam.auth; import org.apache.wicket.markup.html.WebPage; import org.apache.wicket.markup.html.form.Form; import
Re: Help with integrating NTLM in wicket application
Thanks, this pointed me in the wrong direction. I then ended up calling this
from within the onBeforeRender method to get it to handle the redirect
correctly on login. Another issue was that I was calling another part of the
code and should have been calling AuthenticatedWebSession.get().signIn
So, what I was now trying is to have the login process handle the situation
when a windows / ntlm userid is not found and fall back to the 'legacy' form
based log in.
I am able to display the form, however, the form post never seems to work.
Checking the source code of the html sent to the browser, the form is
defined there, and if I construct a url with the form fields it works, and
the fields are available inside the wicket code. But they're not there when
I post the form.
If I set a property to ignore the ntlm process and start with a new browser,
the login form works fine.
Any thoughts? I guess I'll try and compare the html generated to see if
there is any difference. I'll also double check the program flow if the ntlm
is called but the authentication fails.
Thanks - Bryan.
On Sun, Mar 21, 2010 at 9:17 PM, Josh Chappelle jchappe...@4redi.comwrote:
Bryan,
We have an NTLMPage that we redirect the browser to. If there is no
authorization header this is what we do.
String auth = request.getHeader(Authorization);
if (auth == null)
{
setRedirect(false);
response.setHeader(WWW-Authenticate, NTLM);
throw new AbortWithHttpStatusException(401, false);
}
I hope this helps.
Thanks,
Josh
-Original Message-
From: Bryan Montgomery [mailto:mo...@english.net]
Sent: Friday, March 19, 2010 3:36 PM
To: users@wicket.apache.org
Subject: Help with integrating NTLM in wicket application
Hello,
I have two applications, one a stand alone web app and one wicket based.
Currently they both use form authentication however I am trying to add NTLM
authentication for SSO from our windows intranet.
Leveraging jcifs, I've been able to do this pretty easily with the stand
alone web app. However I've been struggling over the last couple of days
with the wicket app.
I'll preface this with the caveat that I have only done some very simple
stuff with wicket to date.
The flow is that the user makes a request and the program flow is
redirected
to LoginPage, and in turn to LoginPanel. In LoginPanel the first thing it
does is check if there is an authentication header, if not which is the
case, it sets the status to SC_UNAUTHORIZED and adds a header of
WWW-Authenticate: NTLM. I then started with flushing the response and not
adding anything else.
In theory this response should tell the browser to resubmit the same
request
with the authentication information. However, from our log files I can see
that the request second time around only has the Login in the request
cycle,
compared to the startup page being in the request cycle initally.
After looking on the web I've tried various combinations including trying
continueToOriginalDestination in the onBeforeRender method.
One thing I've noticed is that it seems that setting the status and header
on the
((WebResponse)response).getHttpServletResponse() only takes effect when I
do
not call flushBuffer() on it. This subseqently throws an exception in the
wicket processing because the response has already been closed.
I feel that I am so close - but can't quite get it right!
I was hoping to integrate this with minimal changes to the code but am
thinking that maybe I should start from scratch? I've found a few posts
online of similar situations but I haven't been able to put all the pieces
together yet.
Appreciate the help in getting this sorted out.
Thanks,
Bryan.
http://markmail.org/message/cjy4o4ndtigius55#query:+page:1+mid:t3foamferfh2t
wwj+state:results
http://old.nabble.com/Wicket-NTLM-Single-sign-on-integration-Question-td1786
8669.html
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Help with integrating NTLM in wicket application
oops, sorry Josh. I appreciate your hlelp. I _meant_ to say pointed me in
the RIGHT direction. Brain and fingers weren't connecting as I was trying to
finish sending before leaving the office! Though this looks like it will be
cleaner than what I currently have, thanks again.
On Wed, Mar 24, 2010 at 8:49 PM, Josh Chappelle jchappe...@4redi.comwrote:
Bryan,
Sorry for pointing you in the wrong direction. Below is the NTLMPage that
we
use. Notice that it redirects the user to the login page if it can't log
them in through NTLM. I hope this helps.
import java.io.IOException;
import javax.servlet.http.*;
import jcifs.ntlmssp.Type3Message;
import jcifs.util.Base64;
import org.apache.wicket.RestartResponseAtInterceptPageException;
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.protocol.http.WebRequest;
import
org.apache.wicket.protocol.http.servlet.AbortWithHttpStatusException;
public class NTLMPage extends WebPage
{
public NTLMPage()
{
HttpServletRequest request =
((WebRequest)getRequest()).getHttpServletRequest();
HttpServletResponse response =
getWebRequestCycle().getWebResponse().getHttpServletResponse();
String auth = request.getHeader(Authorization);
MySession session = MySession.get();
setStatelessHint(true);
if (auth == null)
{
setRedirect(false);
response.setHeader(WWW-Authenticate, NTLM);
throw new AbortWithHttpStatusException(401, false);
}
if (auth.startsWith(NTLM ))
{
byte[] msg;
try
{
msg = new
sun.misc.BASE64Decoder().decodeBuffer(auth.substring(5));
if (msg[8] == 1)
{
byte z = 0;
byte[] msg1 =
{(byte)'N', (byte)'T', (byte)'L',
(byte)'M', (byte)'S',
(byte)'S',
(byte)'P', z,
(byte)2, z, z, z, z,
z, z, z,
(byte)40, z, z, z,
(byte)1, (byte)2, (byte)8, z,
z, (byte)2, (byte)2,
(byte)2, z, z, z, z,
z, z, z, z, z, z, z,
z};
setRedirect(false);
response.setHeader(WWW-Authenticate, NTLM + new
sun.misc.BASE64Encoder().encodeBuffer(msg1).trim());
throw new
AbortWithHttpStatusException(401, false);
}
else if (msg[8] == 3)
{
getSession().bind();
final Type3Message type3msg = new
Type3Message(Base64.decode(auth.substring(5)));
if(type3msg.getUser() != null)
{
User user = new UserImpl();
user.setUserName(type3msg.getUser());
session.setDomain(type3msg.getDomain());
session.setHostname(type3msg.getWorkstation());
session.setUser(user);
}
}
}
catch (IOException e)
{
e.printStackTrace();
}
}
if(session.getUser() == null)
{
setResponsePage(LoginPage.class);
}
else
{
setRedirect(false);
throw new
RestartResponseAtInterceptPageException(HomePage.class);
}
}
@Override
public boolean isVersioned()
{
return false;
}
}
-Original Message-
From: Bryan Montgomery [mailto:mo...@english.net]
Sent: Wednesday, March 24, 2010 3:31 PM
To: users@wicket.apache.org
Subject: Re: Help with integrating NTLM in wicket application
Thanks, this pointed me in the wrong direction. I then ended up calling
this
from within the onBeforeRender method to get it to handle the redirect
correctly on login. Another issue was that I was calling another part of
the
code and should have been calling AuthenticatedWebSession.get().signIn
So, what I was now trying is to have the login process handle the situation
when a windows / ntlm userid is not found and fall back to the 'legacy'
form
based log in.
I am able
Help with integrating NTLM in wicket application
Hello, I have two applications, one a stand alone web app and one wicket based. Currently they both use form authentication however I am trying to add NTLM authentication for SSO from our windows intranet. Leveraging jcifs, I've been able to do this pretty easily with the stand alone web app. However I've been struggling over the last couple of days with the wicket app. I'll preface this with the caveat that I have only done some very simple stuff with wicket to date. The flow is that the user makes a request and the program flow is redirected to LoginPage, and in turn to LoginPanel. In LoginPanel the first thing it does is check if there is an authentication header, if not which is the case, it sets the status to SC_UNAUTHORIZED and adds a header of WWW-Authenticate: NTLM. I then started with flushing the response and not adding anything else. In theory this response should tell the browser to resubmit the same request with the authentication information. However, from our log files I can see that the request second time around only has the Login in the request cycle, compared to the startup page being in the request cycle initally. After looking on the web I've tried various combinations including trying continueToOriginalDestination in the onBeforeRender method. One thing I've noticed is that it seems that setting the status and header on the ((WebResponse)response).getHttpServletResponse() only takes effect when I do not call flushBuffer() on it. This subseqently throws an exception in the wicket processing because the response has already been closed. I feel that I am so close - but can't quite get it right! I was hoping to integrate this with minimal changes to the code but am thinking that maybe I should start from scratch? I've found a few posts online of similar situations but I haven't been able to put all the pieces together yet. Appreciate the help in getting this sorted out. Thanks, Bryan. http://markmail.org/message/cjy4o4ndtigius55#query:+page:1+mid:t3foamferfh2twwj+state:results http://old.nabble.com/Wicket-NTLM-Single-sign-on-integration-Question-td17868669.html
