When running ASPNetBoilerplate in debug mode, if I have a breakpoint in my controllers, when I access the site from the url, the breakpoint is accessed twice. is there something I might have changed that would cause this.
(breakpoint on HomeController/Index even fires twice).
try with different browser. some browsers resend the request if it fails. so when you wait on the debug line it might be trying to resend the request.
another option; clear breakpoints and write a log to see the behavior.
Related
We have a JSF webapp with Primefaces 4.0 and CAS Single Sign On.
When a user requests an ajax action (by clicking a p:commandButton or similar component with ajax=true) after he has lost his session because SSOut in another tab, nothing happens, no response from server or action is triggered.
We need to manage that situation to inform the user that his session is no longer available, by showing a dialog or redirecting him to home or a custom page, but we don't know how.
ajax=false solves the problem, but this is not what we want to do.
No ViewExpiredException is thrown.
EDIT:
We had already read and tried this BalusC's solution without success. No Exception is thrown and Handler has nothing to do. Note that isn't an Expired Session or Invalidated by TimeOut session, is just an explicit session.invalidate caused by Cas Sign Out in another tab.
We also tried javascript jsf.ajax.addOnError() solution, and again nothing to capture.
Only p:ajaxStatus onError event catches something, but no way to identify that particular error. Even overriding ajaxStatus javascript function, error data parameter is undefined...
Also, p:log says "Request return with error:error." but, which error is it? how do we identify it?
We are stuck on this issue...
This has been discussed many times, and as far as know there aren't any out-of-the-box solutions yet. One solution is to add a custom ExceptionHandler as stated in this post.
Another option is to register client error handler using jsf.ajax.addOnError(...), and to handle this exception in it. You might need some server code to add a custom header in case session is invalid, which you would use in error handler to be able to differentiate that specific case from other errors.
I have a page which will send some ajax request to my Jetty7.6.9 server. All of them containing a COOKIE named JSESSIONID so that the server knows the request is logged in.
But sometimes, the method org.eclipse.jetty.server.Request.getCookies() returns an empty Cookie[]. I set a breakpoint and checked the _connection._requestFields and I found the Cookie right there, but Request.getCookies() cannot fetch it or parse it.
The situation can happen in any one or more ajax request in that page, can happen in any time, can happen in both windows and linux. It seems that it's a random case, and even when I dropped the frame at the breakpoint to the pre line, it would run correctly when it ran to the same place, so I think it's an issue about synchronize/concurrent.
I didn't find the same case in jetty bug list.
Is it a bug? What can I do to verify or repeat it? How to fix it?
(For some reason,maybe I cannot update the Jetty version for our system.)
This thing just seems to give me problem after problem.
I posted another question earlier, trying to solve the problem of retaining my session state between closing and opening through Watir. Firefox achieves this on its own, so I figured if I just set the preferences correctly, it'd save my state. I ended up having to go into the selenium-webdriver source and make some changes in order to achieve this in reality.
So, I was just testing my application. Part of its behavior is to loop through a bunch of pages and extract text from them. While it's looping, I simply have it in a while true loop, and figured "hey, I can just stop the program with Ctrl+C". Well, this worked fine up to now, until it came to saving the states.
Ctrl+C causes it not to save its state. My guess as to why is that you need to actually close the browser (and I actually recreated the bug in IRB, so I'm pretty sure this is the case). Simple, right? Why not just use an ensure block with #browser.close in it? That was my first thought.
So, when I try it this way, it does hit the ensure block, and the ensure block calls a method called kill. Kill calls #browser.close if #browser.exists?. The problem is that when it tries to execute this line, I get a nice long list of errors leading up to selenium-webdriver. It seems as if it's trying to make an HTTP request as part of its close functionality, and is failing because, perhaps, Ctrl+C exited the application.
The stack trace is located at https://gist.github.com/Inkybro/5557085
The very last thing I thought was that maybe I needed to let any calls to the #browser object complete, so I placed a bunch of trap('INT', 'IGNORE') and trap('INT', 'DEFAULT') lines around these pieces of code. This also doesn't seem to do the trick.
I'm not really sure as to why, which is why I'm posting here. What I think needs to happen is that whatever processing is going on at the time of Ctrl+C needs to finish processing before #browser.close can be called. If anybody has experience with Watir and/or Selenium, or even if you don't, perhaps you could help me out?
Are you supposed to be testing the browser itself, or your product? Because really, if you are doing things like above, (logging in, closing and re-opening the browser to see if you are still logged in) it sounds to me like you are basically testing the browser's ability to store and read cookies and properly provide them when making requests of a page.
What about if you presume for a moment that the browser in fact does what it is supposed to do with regard to cookie management and usage? If you do that, then what becomes important? I think it would be that your app tells the browser to create the proper cookie, with the proper contents.
So maybe rather than actually trying to test that firefox will in fact use it's cookies correctly (or any other browser doing that for that matter) why not simply test that when the user has logged in, that the proper cookies have been created? You may also have to test that the cookie is updated periodically so that a user's session does not expire while they are actively using the site. again pretty easy to test by just looking at the cookies
You might also want to test that your server is sensitive to changes in the cookie, or a missing cookie. That the server is looking at the cookie and is not depending on session variables is also pretty easy to test, login, alter or clear the cookie, try to access a page and see if it fails.
So with that you get three things
1) Proper cookies created upon login.
2) Cookies kept updated as various pages are accessed.
3) Missing or altered cookie == no soup for your user.
(#4 site works properly if cookies present is implied by the three above and all the rest of your tests that exercise your site/app)
Stop trying to do the work of the mozilla test team, and refocus on testing your application.
I'm still not sure what you try to achieve, but this hacky piece of code ensures browser is closed on Ctrl+C and no your exception is raised:
require 'watir-webdriver'
begin
browser = Watir::Browser.new
loop do
# some code
end
rescue SystemExit, Interrupt
puts 'Exiting!'
ensure
begin
browser.close
rescue Errno::ECONNREFUSED
# do nothing
end
end
My command line testing tool, which uses NSURLConnection, is interfering with Safari's cookies. How do I stop this from happening?
Here's what I'm seeing:
I log into the web site in Safari.
I run my command line based sync tool.
The sync tool logs in, and gets several pages of data. For each request, the cookie rolls over. (The sync tool does not log out.)
I return to Safari and click a link. The link returns me to the login screen.
If I skip step 2-3, the link in Safari works correctly. My tool is clearly the cause of this.
I'm creating my connections like this:
_connection = [[NSURLConnection alloc] initWithRequest: request
delegate: self
startImmediately: NO];
I'm not doing anything explicitly to the cookies, but just letting the default code handle them.
I'm not sure what's really happening here. If Safari and my app really shared the cookies, wouldn't Safari's copy of the cookie also be rolled over? While weird behaviour, everything would work and I wouldn't even know what was happening. This is something else.
Anyway, how can I stop my command line tool from logging people out of their session in Safari?
Seems like the right approach here is turning off default cookie handling entirely, so it doesn't touch the shared store. You can use -[NSMutableURLRequest setHTTPShouldHandleCookies:NO] to disable the default behavior, then read the cookie headers out of the responses, store them yourself, and insert them back into subsequent URL requests as appropriate.
There are plenty of examples of similar problems littered around the web but none of their solutions seem to fix this particular variation. Any suggestions would be appreciated.
Usually this problem occurs because a rogue link is causing a request for a resources like a favicon or css file to hit the dispatcher more than once, thus causing multiple dispatch processes and therefore multiple rows in your database.
I have checked that all the links on this very simple example page do actually resolve to the resource to which they point.
The session handler is setup as follows:
Zend_Db_Table_Abstract::setDefaultAdapter($db);
Zend_Session::setSaveHandler(new
Zend_Session_SaveHandler_DbTable($config->session->toArray()));
The db logging is setup as follows:
$writer = new Zend_Log_Writer_Db($db, $config->log->tableName,
$config->log->columnMap->toArray());
$logger = new Zend_Log($writer);
Both objects are correctly setup and can read and write to and from the database. Only everything happens twice. If I put a test log message anywhere in the application it is written into the database twice. If I increment three variables with every call to the index action - one stored in the session, one passed around via a Zend_Registry object and another local to the indexAction - only the session variable is incremented by 2. The Apache access log shows the correct amount of requests being fired from the page load and all have good response codes of either 200 or 304 (unchanged).
I have tried disabling all head links.
I have tried disabling the layout entirely.
I have localised everything to the dispatcher and exited before dispatch is run.
In all cases the extra write/increment takes place.
Any thoughts?
Thanks in advance for any help.
I seem to have found and fixed the issue. Chrome (and possibly all Webkit browsers) issues an additional HEAD request on top of the GET which means the application is hit twice and anything session based will be triggered as a result of both requests. My temporary solution is to put the following code near the start of my index.php file.
if ("HEAD" == $_SERVER['REQUEST_METHOD']) {
exit;
}
I hope that helps anyone with the same issue.
Google Chrome always asks for the favicon.ico by making annoying requests to the server. Take care about this in Chrome.
For more information:
http://framework.zend.com/issues/browse/ZF-11502?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#issue-tabs
Thanks to the Sebastian Galenski contribution.