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.
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
We have been using the following library for months:
https://unpkg.com/react#15.3.0/dist/react.min.js
Yes - I know we can just reference 15.3 and get the URL rewrite to the latest, but they released a breaking change. That's another issue for another day. Don't get distracted.
Yesterday this simply stopped working. You'll notice that if you load the URL mentioned, that the file is TRUNCATED. Simply cuts off. This made everything we use react with break. Interestingly, if you go to the following URL (without the .js extension) - things work.
https://unpkg.com/react#15.3.0/dist/react.min
My question is - what the heck happened? Why did the URL we've been using for 8 months suddenly stop working, and who can we get to fix it. In the interim, we had a copy locally that we've started referencing (which we probably should have been doing to begin with, since we don't want the automatic upgrade). When things like this happen, who do you inform?
I'm not sure you'll find the answer as to why this file is no longer working here but based off of the website you could reached out to the creator on twitter: https://twitter.com/mjackson
On the website it says:
SUPPORT
unpkg is a free, best-effort service and cannot provide any uptime or
support guarantees.
i.e. you should probably only use this link if you are messing around with a small project and shouldn't be used for any website where you actually care about the uptime of the site.
I have used zend session as bellow..
$test = new Zend_Session_Namespace('test');
$test->test = "test text";
But when i move from one step to another step its working fine and echoes value Not on step3. even i tried using $_SESSION direct (because am desperate this to work ). But i have same problem that session not stored. Site seems almost broken when i use mozilla and IE. Not only in my PC But i have tested in multiple systems.
Tried clearing cookies, used cookie enabled browser only.
SO please suggest me what could be the posible problem in doing above. even i have inserted zend_session::start();
Thanks in advance,
Sanjeevk,
You haven't provided any useful code for what you are trying to accomplish, so I'm going to guess.
I have encountered a problem similar to this as well. My issue was simply trying to persist a page number from the paginator so I could perform an operation on a record and then return to the same page in the previous action.
The problem I was having was that the controller would overwrite the session data every time I called the action (page refresh), so while the page number would persist to other actions as soon as I called the original action the session would be over written and the page would reset to 1.
My solution was to get the page number from the view script and then feed it back to the controller later.
//the view script
<?php $session = new Zend_Session_Namespace('page'); $page = $this->paginator->getCurrentPageNumber(); ?>
so now when call $session->page anywhere in my controller/actions the data is still there and doesn't overwrite until the view is actually rendered, which is exactly what I needed.
You may be encountering something similar. Because of the way PHP and Zend Framework operate you may be inadvertently over writing your session data.
If this doesn't help, please provide more information and maybe an answer can be found.
Hope this provides some help or at least hints.
Could anybody help me to understand this issue?The problem is:
I have a two versions of my application that work in parallel. This means that I have sessions already started in one application that I should use in another app.
First version uses PHP sessions ($_SESSION with custom handlers) and second version of application built on Zend Framework and it should use Zend_Session.
So when I try to create new Zend_Session_Namespace("default") instance I get an error that session was already started and it's true.
So the question is — can I initialize Zend_Session object with the data already stored in PHP $_SESSION?
I had similar problem, and figured it out form zend site,
This worked for me:
in .htaccess file do:
php_value session.auto_start 0
For ref check: http://framework.zend.com/manual/en/zend.session.advanced_usage.html
Hope it helps
Ok, I solved this issue, and in case of me the solution is:
In old version I push member's ID into cookie
In new version I fetch that ID and use different sessions system with own handler.
The one thing that may up security and may help avoid collisions it's check member's email using pubcookie.
Hope my solution helps someone.
I'm very new to Perl, and I have absolutely no idea how to approach this. We have an old Perl application which previously used Apache auth; we'd like to replace this with a cookie based form-style authentication. I understand that this is very case-specific, and there is no one answer as such, but some general tips would be much appreciated.
Will I need to edit all .pl files in the website? Or is there a "golden hammer" solution I can use? Is there something on CPAN I can use? We're using Perl v5.8.8 if it matters, and we're using Apache 2 shared hosting. I am happy to provide additional information as is necessary.
For the authentication to be recognized/required, it will need to be checked by the .pl file that initially receives the user's request. So the answer to whether all .pl files will need to be changed depends on how your application is structured:
If the user goes to http://myserver.com/one.pl to do the first thing and http://myserver.com/two.pl to do the second thing, then, yes, you'll need to change them all because they're all receiving requests individually.
If the user goes to http://myserver.com/dispatch.pl?mode=one for the first thing and http://myserver.com/dispatch.pl?mode=two for the second thing and dispatch.pl calls either one.pl or two.pl behind the scenes based on the mode parameter, then you only need to change dispatch.pl, since it's the only one directly receiving requests from the user.
Edited to add: If you're dealing with the first model, then I'd strongly recommend setting up an external module (.pm file) with the cookie-handling code and calling that from each of your individual .pl files instead of duplicating that code all over the place. Ideally, this would let you get by with only a few lines of added code in each .pl:
use MyCookieHandlingModule qw(verify_cookie redirect_to_login);
my $q = CGI->new; # ...unless you're already using CGI in object-oriented mode
redirect_to_login unless verify_cookie($q);
You could do it at a level outside the Perl program.
Thanks for your answers guys, but I eventually decided on CGI::Session::Auth::DBI which works well on shared hosting.