I have not been using -ipmatch with my Session object, I just read up on it and realized I should be.

However, will the functionality of -ipmatch still be limited in the case of transferring a link from one pc to another, where both are behind a router that masks their individual ip's and just shows a common one for the location? (like the way your home computer network ip's are not shown to the outside world, just one ip for your router.)

Any insights as to why this would be?

Because you wrote it that way? :D

one problem is passing/accepting sessionid through urls

the other is accepting sessionid without further checks, like "-ip_match" that ikegami mentions, that prevent https://en.wikipedia.org/wiki/Session_fixation

The simplest solution is to use secure cookies (don't really have to write much if any extra code, all the popular frameworks support it in one way or another)

Dancer2::Session::Cookie - Dancer 2 session storage in secure cookies
Plack::Middleware::Session::Cookie also does tamper evident cookies ( base64 encoded, HMAC SHA1 signed )
https://metacpan.org/module/Mojolicious::Guides::Growing#State-keeping "secure" cookie means tamper-evident/tamper-proof/tampering-obvious , Just remember that all session data gets serialized with Mojo::JSON and stored in HMAC-SHA1 signed cookies, which usually have a 4096 byte limit, depending on browser.

A better solution is to use HTTP digest authentication... but it requires a tad more work on the javascript end ... http://marcin-michalski.pl/2012/11/01/javascript-digest-authentication-restful-webservice-spring-security-javascript-ajax/

After looking up secure cookies, it would appear you have to be on a secure server to use them (and use https for calls). I wouldn't be guaranteed that I could use a secure server on the various customer sites.

Also, I think we wouldn't want to have to move the script and associated files from the regular server to the secure one. (maybe that's not a problem, maybe you can use https from the same folder on the server as before, I'm not certain on that.)

After looking up secure cookies, it would appear you have to be on a secure server to use them (and use https for calls).

secure server? https? No, thats not secure cookies -- sure it enhances "secure cookies" but not a requirement

OK - those are great suggestions. I have some other questions about each of them, I'm investigating some now.

But I was really wondering why does the Windows server allow that cross computer usage of the same session id, but the linux server does not? Any ideas? Is it something fundamental about the Win server or a quirk of Linux?

But I was really wondering why does the Windows server allow that cross computer usage of the same session id, but the linux server does not? Any ideas? Is it something fundamental about the Win server or a quirk of Linux?

Neither -- the problem is your program, not the webserver

      use CGI::Session qw/-ip-match/;
[download]

I also tried adding

$session::IP_MATCH = 1;
[download]

What am I missing here in the use of -ip_match ?

I am not specifically familiar with this module, but logically the first place to begin would be to have a look at the session-store that it uses ... be it a file or a database or whatever it is.   You ought to be able to see the list of tokens, perhaps the IP-addresses with which they are associated, and so on.   And in any case, the software should be checking IPs, session timeout dates, and so forth to be certain that forged or stolen credentials are not being used.   Start by looking at the authoritative session-data source that it’s referring to.   Be sure, for example, that the IP address that it’s seeing does not belong, say, to an internal router or somesuch.