Re^8: Cookie->fetch problem

Hi:

Thanks for observations and timely response. As for the "unknown" cookie, I am sure it is not of my origin and another "monk" suggested that my host is sending this back with each access. I have sent an email to their tech support asking this very question.

As for requesting a "secure" cookie. That was a potential problem. I copied my file with the cookie "try it" button code to my https directory and called https://www.jala-mi.org and it opened the index page there.

This was evidenced by the lack of the insecure login warning appearing from Firefox.

Clicking the "try it" button again returned the unknown cookie listing. Removing that cookie and clicking again returned no result. Try it yourself.

My logon consists of an insecure page with an iFrame which is supplied with and https delivered login form which I assume was secure.

The fact that the Firefox security warning appears suggest that the login form in the iframe is not secure.

I have posted a question on Firefox forum and they disagreed and said it was not secure. I am still disputing that.

Take note that the Firefox warning does not appear when opening the login page from rhe https location confirming that page was secure for my test.

Nonetheless, I think I have explored the avenue you suggested and this problem is not related to the secure path issue unless the fact that the path shown on the CGISESSID cookie: .www.jala-mi.org.

I looked at other cookies requiring a secure connection and the ones I looked at showed a path w/o the www as in .paypal.com .

Other unencrypted connections such as: www.paypal-community.com show the www with no dot in front of it as my cookie does. Perhaps there is something in the structure that is incorrect. I am not familiar with these issue to be able to render a judgment on this aspect.

I did a search on the module providing all the access and turned up no instances of ".www" as did the same search is all the files in the project.

As I said, I am at a loss. Below is code that sets cookie

sub SetUserSessionCookie
{    
    my ($sname,$sid) = @_;
    #use CGI qw/:standard/;
    #use CGI::Cookie;
    my $sessioncookie = new CGI::Cookie(-name=>$sname,-value=>$sid,-ex
+pires=>$session_cookie_timeout,-path=>'/cgi-bin',-domain=>$domain,-se
+cure=>1);
    print header(-Cookie=>[$sessioncookie],-type=>"text/html");
}
[download]

And the code calling the new cookie

       warn("Hash evaluation succeded - $passhash = $passhash1 : $sess
+iondata2 = $sessiondata2md5p");
       my $timein = time();
       $session->param('user_id',$uid);
       $session->param('username',$username);
       $session->param('forename', $forename);
       $session->param('lastname', $lastname);
       $session->param('timein', $timein);
       $session->param('timeout', 0);
       $session->param('attempts',0);
       $session->param('isloggedin',1);
       $session->expires('+7d');
#       Expires($session, Now() + (86400*7));
       AccessInOutLog($session); #Added 02/18/05
       my $isloggedin = $session->param('isloggedin');
       warn("Login User : SID '$sid'  Session Logged In  '$isloggedin'
+");
       $session->flush();

       #Set session cookie on client
       SetUserSessionCookie('CGISESSID', $sid);

       my $gmtimenow = gmtime(Now());
       my $localtimenow = localtime(Now());
       return 3;
    }
[download]

Comment on Re^8: Cookie->fetch problem Select or Download Code

Replies are listed 'Best First'.
Re^9: Cookie->fetch problem by huck (Prior) on Mar 11, 2017 at 18:25 UTC
Nonetheless, I think I have explored the avenue you suggested and this problem is not related to the secure path issue unless the fact that the path shown on the CGISESSID cookie: .www.jala-mi.org. Yes the extra dot could very well be the problem since you seem to use firefox do you know of the web developer section under tools? open a new window, click tools-web developer-network. now enter `https://www.jala-mi.org/httpsdocs/cgi-bin/manage_users.cgi?action=GetLoginForm` into the address bar and press return. watch the fields get filled in in the network section. now click on the `get manage_users.cgi?action=GetLoginForm` line. new tabs open on the right. click on cookies. you can navigate your form in the top window, and look at the cookies sent and received in that window. A very interesting utility. but i just figured out your problem with no cookies. it took me pasting the line here to see it. ill paste it again `https://www.jala-mi.org/httpsdocs/cgi-bin/manage_users.cgi?action=GetLoginForm`. look close, look closer, closer again. WHAT IS THE PATH to manage_users.cgi? does that look like /cgi-bin? no huh. that path is /httpsdocs/cgi-bin isnt it? why you are linking to /httpsdocs/cgi-bin i cannot say. i notice that `https://www.jala-mi.org/cgi-bin/manage_users.cgi?action=GetLoginForm` give me a 404. but i can say that the path you are running the login form from IS NOT /cgi-bin like your set cookie of `-path=>'/cgi-bin'` is setting	[reply] [d/l] [select]
Re^10: Cookie->fetch problem by huck (Prior) on Mar 12, 2017 at 01:42 UTC
the extra dot should not be the problem, i found out it comes from explicitly setting the domain with -domain. With the leading dot the cookie is sent back to www.jala-mi.org or any domain ending in .www.jala-mi.org like subserver.www.jala-mi.org	[reply]
Re^10: Cookie->fetch problem by tultalk (Monk) on Mar 12, 2017 at 03:05 UTC
Hi: Thanks for critique. I had never seen the the response from you before. Lost. Issue: WHAT IS THE PATH to manage_users.cgi? does that look like /cgi-bin? no huh. that path is /httpsdocs/cgi-bin isnt it? </p I tried /httpsdocs/cgi-bin which is where the module is stored. I also put a copy of the index.html in the httpsdocs directory to try calling through https. I am going back and forth on this. i notice that https://www.jala-mi.org/cgi-bin/manage_users.cgi?action=GetLoginForm give me a 404. The 404 is because manageusers.pm is running from httpsdocs/cgi-bin/lib/perl/ So what should the path in the cookie be? Better yet, what is the path pin the cookie used for?	[reply]
Re^11: Cookie->fetch problem by huck (Prior) on Mar 12, 2017 at 03:48 UTC
if may be best for now to skip the whole -path thing. if you do that then the path gets set to / and that cookie gets returned to any page request on your site. The path is matched to the stuff right after your webserver name, and if they dont match then the cookie doest get sent back. so with path set to /cgi-bin only requests to https://www.jala-mi.org/cgi-bin/something would get that cookie sent back	[reply]
Re^11: Cookie->fetch problem by tultalk (Monk) on Mar 12, 2017 at 04:17 UTC
A very interesting utility. It is indeed and shows the cookie in question associated with that (login)form that is loaded in the iframe from manage_users.cgi located in httpsdocs/cgi-bin	[reply]
Re^9: Cookie->fetch problem by tultalk (Monk) on Mar 11, 2017 at 13:45 UTC
Strange I just looked at the "invisible" CGISESSID cookie again and now the path is /cgi-bin but it still does not show up clicking the "try it" button on the form returned by https://www.jala-mi.org.	[reply]
Re^10: Cookie->fetch problem by tultalk (Monk) on Mar 11, 2017 at 15:03 UTC
Perhaps my $domain = $ENV{'HTTP_HOST'}; and $domain in set cookie -domain=>$domain,-secure=>1); Who knows???	[reply]
Re^11: Cookie->fetch problem by Anonymous Monk on Mar 11, 2017 at 21:29 UTC
Who knows??? I know Let me repeat, you can't debug this piecemeal, its Re^11 and the problem is still unresolved, If you want to actually figure it out you need to post a complete program Or spend a week or a month reading docs, creating and debugging cgi programs, until you gain enough experience , to where you can post some short snippet, and figure out the problem Look for example at these links and the links they link , and parents, and get a birds eye view of similar confusion Re^3: CGI::Session keeps re-using same session ID Re^5: Problems getting session management to work: is_expired seems to lie to me (cookies) Re: perl CGI::Session not deleting the session People are happy to try to debug stuff piecemeal ... its simply not a workable approach when both sides have knowledge holes	[reply]