Re^9: Cookie->fetch problem

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

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

Replies are listed 'Best First'.
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]