I've loaded a saved session from yesterday and some requests are stricken out, what's the meaning of this?
You can right-click the Session and choose Properties to determine the reason for the ui-strikeout within the Session's flags.
Related
I need to update a javaEE application (still in java 1.7) that provides a SOAP web service. And I'd like to disable the TIMESTAMP_CACHE that wss4j (v2.0.2) uses to control reply attacks. It creates too many files and the OS reaches the maximum open files allowed, repeatedly. The files start to appear, one for each request that has been made and are named in the following way:
wss4j%002etimestamp%002ecache-e%0058ga%0058l%0058%004b%0057g%004ah%0050w==.data
The documentation states that the TIMESTAMP_CACHE can be changed (or so I understand):
ConfigurationConstants.ENABLE_TIMESTAMP_CACHE ("enableTimestampCache"): Whether to cache Timestamp Created Strings (these are only cached in conjunction with a message Signature). The default value is "true".
I've found many examples to change some of these ConfigurationConstants when a client application creates the Call object. See an example to change the PASSWORD_TYPE constant:
Service service = new Service();
Call call = (Call) service.createCall();
...
call.setProperty(UsernameToken.PASSWORD_TYPE, WSConstants.PASSWORD_TEXT);
call.setProperty(WSHandlerConstants.USER,"werner");
However, my application is not on the client side but on the server side and I haven't found so far the way to change the ENABLE_TIMESTAMP_CACHE constant.
Any idea?
I couldn't find a way to disable the timestamp cache. However, the wss4j behaviour described above happened to be a bug that not only resulted in lots of open files but in lots of open threads. It has already been fixed in version 2.0.9. Upgrading to the "newer" version did the trick.
You can find here the discussion in full that drove to the bug discovery and here the fix in wss4j's jira
I added a rule (flash file), specified the new flash file I want fiddler to respond with (use instead of the browser one). I've cleared my browser cache, and every time I play the stream, the browser flash file is captured again (instead of auto-responding) with the one saved already!!!
It used to work just fine, but now it appears as if the auto-responder (although checked) is not working at all...it's just a pass-through!!!
As explained in the forum post where you asked the same question
There are three possibilities:
1> The AutoResponder itself is disabled (checkbox at the top)
2> The AutoResponder rule is disabled (checkbox at the left of the rule)
3> The rule you've written doesn't match the target request's URL.
Sharing a screenshot of Fiddler might help me tell you which problem you're encountering.
On the top of the list EricLaw gave in the previous answer, I add a new one:
You need to ensure your Fidler has the "Capturing Traffic" mode enabled. Either press F12 or go to "File" -> "Capture Traffic" and make sure you have a "Capturing.." icon on your left bottom corner.
I had a similar issue, and I solved it by enabling decryption of HTTPS traffic.
You can do this by going to Tools > Options > , then check Decrypt HTTPS Traffic
I had the same problem. I drag-dropped from the left, "main", window into the autoresponder so the "request matches..." column auto-populated. As a sanity check I unchecked "unmatched requests passthrough" to ensure that the match rule was indeed picking it up. If it hadn't nothing would appear in the main window at all. But it did appear so the rule was matching.
The issue with Fiddler is in the "then respond with..." column. Right-click for "Edit Response...", edit the response in the popup window of tabs, press Save, close the box.
When you retry your URL, your edited response isn't returned. Fiddler returns the original response. Even if you Edit Response again, it'll show what you typed in, but it never actually returns it.
To fix, you have to save the intended response to a file on your hard drive and edit it there.
When I tried this:
while (my $cgi = new CGI::Fast) {
...
my $session = CGI::Session->new(undef, $cgi);
...
}
I discovered that different clients were getting the same session! What would be causing this bizarre session-sharing?
EDIT: I can't reproduce this reliably but in my testing, I have seen cases where I delete the session cookie from the browser, refresh the page, and (using Firebug's Net pane) see that I'm not sending a cookie in the request but get a Set-Cookie in the response with an old session ID! Perhaps something is sticking in memory due to using FastCGI?
(Note: I removed a 2nd piece of code from an earlier version of this question because I'm no longer sure it's relevant)
EDIT: This http://osdir.com/ml/web.fastcgi.devel/2004-02/msg00007.html seems to be describing the behavior I'm seeing
EDIT:
As mentioned in the above osdir.com posting, FCGI.pm contains this code:
for (keys %FCGI::ENV) {
$ENV{$_} = $FCGI::ENV{$_} unless exists $ENV{$_};
}
This seems quite clearly flawed to my eyes. It is copying from a persistent copy of environment variables into the copy of the environment visible to the script whenever the current request does not supply a value for a given variable. So if a request comes in with no cookies, then it won't find HTTP_COOKIE defined so it will give the script the cookies from the last request that sent them, meaning some other session! I don't get how this code could possibly be correct, and this is a very highly used module!
I fixed this bug about seven months ago, you need to upgrade CGI.pm to >= 3.56. CGI::Fast was using an FCGI API that was deprecated and removed from documentation more than ten years ago.
Are you using mod_perl? If so, global variables will persist across requests, and this will be intermittent because it will depend on whether the request is handled by the same apache httpd process or not, which will depend on site load and other variables.
In our app we need to check if the data is saved when we are in a particular place before navigating away from it. So the user should be able to negate a browser back button request. But by the time that the history value change event is received the url has already been changed. The History class doesn't seem to have a way to restore the url back. Anybody have any ideas?
In GWT 2.1 you get Activities and Places. And activity has a maystop method, which is exactly what you want, if I understand you correctly.
Use a window.onunload or window.onbeforeunload javascript callback to confrim/save state.
onbeforeunload example
I haven't actually implemented this behavior yet, but here is my plan and maybe it will work for you.
1) Each time you receive an onHistoryChanged event and decide to allow it, save the current historyToken in an instance variable somewhere.
2) Keep track of activity on the page that should block navigation. Use a data structure that can keep track of multiple activities, like multiple file uploads, multiple edits, etc.
3) When you receive a new onHistoryChanged event, if your data structure from #2 indicates that it's not safe to navigate, avoid changing the page and restore the historyToken that you saved in #1. I'm assuming that you can do this either by:
a) Calling History.newItem(oldHistoryToken, false) or
b) Calling History.newItem(oldHistoryToken, true) and keeping a flag to force the next onHistoryChanged to be ignored.
Again, I haven't actually implemented this so let me know how it works out.
If you have links that allow the user to leave the app and you want to prevent that as well, you'll need to also add an onbeforeunload.
Have a look at the PlaceManagerImpl class from the gwt-platform framework. Especially the onValueChange() method and the methods dealing with the onLeaveQuestion field.
Hope that helps.
In this issue report, t.broyer explains in his comment that such behavior was planned during design of Places framework. The most important part is:
mayStop was a mistake, or it should have only been called when unloading the app, not for internal navigation within the app.
So probably it's better to not use it at all...
Follow up to this:
Why can't I pass user sessions between subdomains?
I followed the advice there and used :
ini_set('session.cookie_domain','mydomain');
(with and without a dot before mydomain) as the first line of index.php in the public folder as advised there and in other links around the web.
The problem is that it completely "ruined" Zend_Session_Namespace inside my application.
While it persisted among calls (as it should) of the page, now every time it is being called it is behaving as a new session is being instantiated, without holding all variables.
Any ideas on how to fix this?
Have you tried setting the cookie domain via Zend_Session?
$config['cookie_domain'] = 'mydomain';
Zend_Session::setOptions($config);