[ic] Patch: Remove REMOTE_USER From Session Name

[Mike Heins]

Go ahead and remove it. It'll give me a good laugh if someone turns out to
need it and we have to add the pragma. :)

On Mon, Apr 6, 2020 at 3:14 PM Mark Johnson <mark at endpoint.com> wrote:

> On 4/6/20 1:23 PM, Mike Heins wrote:
> > On Mon, Apr 6, 2020 at 10:46 AM Jon Jensen <jon at endpoint.com> wrote:
> >
> >> On Sun, 5 Apr 2020, Mike Heins wrote:
> >>
> >>> Certainly could put
> >>>
> >>> if($Pragma->{session_remote_user} and defined $CGI::user and
> $CGI::user)
> >>> {
> >>>        $host = escape_chars($CGI::user);
> >>>    }
> >>>    elsif($Pragma->{session_remote_user} and $CGI::cookieuser) {
> >>>        $host = $CGI::cookieuser;
> >>>    }
> >>>    elsif($CGI::cookiehost) {
> >>>        $host = $CGI::cookiehost;
> >>>    }
> >>>
> >>> and allow for any users where this would break them. Though I doubt
> there
> >>> would be any.
> >>
> >> I like that idea if anyone reports breakage, but since
> >> "session_remote_user" isn't an existing pragma, someone who needs it
> >> probably wouldn't notice it in our release notes and wouldn't use it, so
> >> would get breakage anyway. 😊 Might as well just wait till that
> happens
> >> and add it then, and avoid supporting a likely unused feature.
> >>
> >> The only purpose of this behavior that I can think of is that users
> >> authenticated with HTTP basic auth can move between IP addresses *and*
> >> without a cookie, and not lose their session. Anyone know otherwise?
> >>
> >> Maybe the biggest question is when the last time was that anyone used
> HTTP
> >> basic auth for user authentication at all, much less depended on the
> >> session sticking without cookies ...
> >
> > Well, I did use it for a bifurcated admin server that required HTTP Basic
> > authorization, but I am guessing that was 2005 or so. :) As I said,
> > probably affects no one. I just have always put a workaround in anytime I
> > break something instead of leaving it high and dry, but at this point I
> > doubt it matters.
>
> So prospective patches based on both approaches. I'm inclined to full
> removal, but am satisfied with either approach since the pragma approach
> disables by default.
>
> Mark
> _______________________________________________
> interchange-users mailing list
> interchange-users at interchangecommerce.org
> https://www.interchangecommerce.org/mailman/listinfo/interchange-users
>


-- 
Just because something is obviously happening doesn't mean something
obvious is happening. --Larry Wall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.interchangecommerce.org/pipermail/interchange-users/attachments/20200406/a5c188ba/attachment.htm>