Thanks again Dmitriy, and yes of course I have reproduced locally :-) The HTTP 302 is certainly interesting. It's almost as if the POST is failing (my guess is a bug or misconfiguration of Spring Webflow properties) and redirecting the user to the login screen (hence the "form resetting" behavior). I really think this is an issue with Spring Webflow.
From: Dmitriy Kopylenko [mailto:dkopyle...@unicon.net] Sent: Friday, June 27, 2014 2:27 PM To: cas-user@lists.jasig.org Subject: Re: [cas-user] CAS: Broken webflow on failed authentication on 4.0.0? Have you tried to reproduce it in the locally deployed let's say standalone Tomcat instance? D. On Jun 27, 2014, at 2:23 PM, Zac Harvey <zhar...@commercehub.com<mailto:zhar...@commercehub.com>> wrote: Thanks Dmitriy, however: Browser culprit? I can reproduce this in *any* browser, although it seems more difficult to reproduce in Chrome. Nginx culprit? The link (http://mycas.commercehub.cloudbees.net/login) is my CAS server running on the CloudBees PaaS. I put it up there so the CAS community could actually reproduce what I'm seeing. Normally, this app is hosted from inside my org's internal network and is not publicly available. As far as I know our data center/infrastructure does not use Nginx at all. And I'm 100% sure that CloudBees has a much different infrastructure stack than what we use! So this is a problem that transpires network stack/topology/technologies and is definitely a problem with CAS itself. From: Dmitriy Kopylenko [mailto:dkopyle...@unicon.net] Sent: Friday, June 27, 2014 2:16 PM To: cas-user@lists.jasig.org<mailto:cas-user@lists.jasig.org> Subject: Re: [cas-user] CAS: Broken webflow on failed authentication on 4.0.0? Here's some insight into this req-resp - on the second HTTP POST with correct credentials, HTTP 302 is returned and browser simply re-issues GET to the /login resource: Remote Address:75.101.143.131:80 Request URL:http://mycas.commercehub.cloudbees.net/login<http://mycas.commercehub.cloudbees.net/login> Request Method:POST Status Code:302 Found Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Accept-Encoding:gzip,deflate,sdch Accept-Language:en-US,en;q=0.8,ru;q=0.6 Cache-Control:max-age=0 Connection:keep-alive Content-Length:137 Content-Type:application/x-www-form-urlencoded Cookie:JSESSIONID=9E5C40753758BC75CDC6A9FE5344FD28 Host:mycas.commercehub.cloudbees.net Origin:http://mycas.commercehub.cloudbees.net<http://mycas.commercehub.cloudbees.net/> Referer:http://mycas.commercehub.cloudbees.net/login;jsessionid=9E5C40753758BC75CDC6A9FE5344FD28<http://mycas.commercehub.cloudbees.net/login;jsessionid=9E5C40753758BC75CDC6A9FE5344FD28> User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36 username:dummy password:12345 lt:LT-124-z9dnswJnrDmWWEpWVDTJJsZgusHyD9-localsso.example.com<http://124-z9dnswjnrdmwwepwvdtjjszgushyd9-localsso.example.com/> execution:e1s2 _eventId:submit submit:SIGN IN Response Headersview source Cache-Control:no-cache Cache-Control:no-store Connection:keep-alive Content-Length:0 Date:Fri, 27 Jun 2014 18:04:04 GMT Expires:Thu, 01 Jan 1970 00:00:00 GMT Location:http://mycas.commercehub.cloudbees.net/login<http://mycas.commercehub.cloudbees.net/login> Pragma:no-cache Server:nginx/1.4.2 Browser culprit? Nginx webserver culprit? No culprit? Cheers, Dmitriy. On Jun 27, 2014, at 1:22 PM, Zac Harvey <zhar...@commercehub.com<mailto:zhar...@commercehub.com>> wrote: I am on CAS 4.0.0 and am experiencing what I *believe* is a bug in the login webflow. To see this yourself: 1. Go to http://mycas.commercehub.cloudbees.net/login (my DEV/dummy CAS server). 2. Enter username of "dummy" 3. Enter password of "abc" and hit [ENTER] or slick the "Sign In" button 4. You'll get an error: "The username or password that you supplied is incorrect." (the password is bad) 5. Re-enter the correct password: "12345" 6. The login form resets! Both username and password clear, whereas it should have logged you in 7. Re-enter username/password with correct values ("dummy"/"12345" without the quotes of course) 8. About 50% of the time it will allow you to login, and about 50% of the time it will just reset the login form again. If this happens, it will never log you in; every time you login with good credentials it will just do a form reset. The only way to fix this is to hit F5 (page refresh), and you can then login with success. This happens in all browsers and does not happen unless your logins fail. Anybody know why this could be happening? Thanks in advance! -- You are currently subscribed to cas-user@lists.jasig.org<mailto:cas-user@lists.jasig.org> as: dkopyle...@unicon.net<mailto:dkopyle...@unicon.net> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org<mailto:cas-user@lists.jasig.org> as: zhar...@commercehub.com<mailto:zhar...@commercehub.com> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org<mailto:cas-user@lists.jasig.org> as: dkopyle...@unicon.net<mailto:dkopyle...@unicon.net> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org<mailto:cas-user@lists.jasig.org> as: zhar...@commercehub.com<mailto:zhar...@commercehub.com> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user