Codeigniter: Session_database_driver Uses Proxy IP Address

[Haravikk]

I realise this is a duplicate of #5539 and earlier, however I do not feel this issue has ever been correctly addressed, so please don't immediately close this.

The problem is that when using a site in a proxied setup, the Session_database_driver will store the proxy's IP address, rather than that of the connecting client, even if you have correctly configured $config['proxy_ips'] and $CI->input->ip_address() is returning the correct value.

Previous issues have been closed with a dismissal that other headers can't be trusted, however this is IMO the incorrect resolution, as it doesn't solve the actual problem (that the IP addresses in the table are useless) and it isn't strictly true.

While yes, if you are trusting user supplied headers then they represent a security risk, and CodeIgniter should clearly warn of this, in the majority of proxied setups forwarding headers are not supplied by users, but instead are supplied by the last proxy in the chain, and if you are able to trust that, then you can trust the headers (but should always check and be absolutely sure what it's header behaviour is). The last proxy will often be a load-balancer, reverse proxy (e.g- for caching) and so-on, and these will usually document their behaviour.

For example, the CodeIgniter site I'm currently working on is running from Google App Engine, which strips out all forwarding related headers and replaces them; so what you get in HTTP_X_FORWARDED_FOR is the IP address of the client. I believe the same is also true for Cloudflare, a popular reverse proxy based caching service.

I would argue that it's not CodeIgniter's place to tell developers that what they are doing is insecure and refuse to do it, but to remind them to check whether it really is insecure and make the judgement for themselves, and then do what they decide, otherwise we just end up with users performing workarounds instead which is arguably worse.

So yeah, I'd like to request that this bug finally be put to bed by having the Session_database_driver fetch IP addresses in the same way as the input library, and simply make sure the documentation is clear on the security risks of using forwarding headers, and/or provide a way to supply a specific header for use (to loop back to the examples above both App Engine and Cloudflare provide alternative headers unique to themselves that could be used for IP fetching, as an alternative to using rewritten forwarding headers).

[narfbg]

I realise this is a duplicate of #5539 and earlier, however I do not feel this issue has ever been correctly addressed, so please don't immediately close this.

Even if a thousand other times this pops up, I'll still immediately close it.

Previous issues have been closed with a dismissal that other headers can't be trusted, however this is IMO the incorrect resolution, as it doesn't solve the actual problem (that the IP addresses in the table are useless) and it isn't strictly true.

Well, that's your opinion.

While yes, if you are trusting user supplied headers then they represent a security risk, and CodeIgniter should clearly warn of this, in the majority of proxied setups forwarding headers are not supplied by users, but instead are supplied by the last proxy in the chain

There's no way of determining who supplied the header, only the sender has that knowledge.

For example, the CodeIgniter site I'm currently working on is running from Google App Engine, which strips out all forwarding related headers and replaces them; so what you get in HTTP_X_FORWARDED_FOR is the IP address of the client. I believe the same is also true for Cloudflare, a popular reverse proxy based caching service.

So setup your httpd to replace REMOTE_ADDR with the HTTP_X_FORWARDED_FOR value ... It's a 1-liner in nginx, I can't imagine it being much harder in Apache and others.

I would argue that it's not CodeIgniter's place to tell developers that what they are doing is insecure and refuse to do it, but to remind them to check whether it really is insecure and make the judgement for themselves, and then do what they decide, otherwise we just end up with users performing workarounds instead which is arguably worse.

Not once has this worked for us. You may be savvy enough to deal with such decisions, but I see people making the wrong decisions on a daily basis (not exaggerating even a bit about this).

So yeah, I'd like to request that this bug ...

It's not a bug.

[Haravikk]

Even if a thousand other times this pops up, I'll still immediately close it.

Then you'll be wrong to do-so a thousand times.
And I specifically asked to keep it open so that this can actually be properly discussed; if I have to post another issue in order to respond then that's going to be on you.

Well, that's your opinion.

No it's not; you've claimed in the past that the headers can't be trusted, but this is provably false in cases where you always know where they've come from. That's not opinion, it's simple objective fact.

There's no way of determining who supplied the header, only the sender has that knowledge.

If my site is only accessible through a proxy (which is the case for Google App Engine sites, sites using CloudFlare with origin pull certificates etc.), and the headers are supplied by the proxy then it is known exactly where the headers came from. Again, this is not simply opinion.

So setup your httpd to replace REMOTE_ADDR with the HTTP_X_FORWARDED_FOR value ... It's a 1-liner in nginx, I can't imagine it being much harder in Apache and others.

It's not a one-liner in Google App Engine and similar platforms. And what you're suggesting is solving a problem outside of CodeIgniter that should be solvable within it. CodeIgniter even already allows this, but only for one library.

Not once has this worked for us. You may be savvy enough to deal with such decisions, but I see people making the wrong decisions on a daily basis (not exaggerating even a bit about this).

I sympathise, but leaving CodeIgniter inconsistent is not going to prevent that nor the myriad other things that people can still do wrong with CodeIgniter by ignoring warnings and recommendations; if people ignore warnings, that's on them.

It's not a bug.

CodeIgniter's handling of IP addresses and headers is inconsistent; are you suggesting that that's a feature? Because I certainly wouldn't want to call it that.

[narfbg]

Then you'll be wrong to do-so a thousand times.

Oh, yea ... I'd be wrong because you said so. Very convincing. :)

And I specifically asked to keep it open so that this can actually be properly discussed; if I have to post another issue in order to respond then that's going to be on you.

So I'm expected to do or not do just as you please? You've got some nerve ...

Previous issues have been closed with a dismissal that other headers can't be trusted, however this is IMO the incorrect resolution, as it doesn't solve the actual problem (that the IP addresses in the table are useless) and it isn't strictly true.

Well, that's your opinion.

No it's not; you've claimed in the past that the headers can't be trusted, but this is provably false in cases where you always know where they've come from. That's not opinion, it's simple objective fact.

You know, I tried to be brief here and leave you room to at least claim a difference of opinion in order to avoid confrontation, but since you're now twisting my words, clearly confrontation is what you're looking for.

Bolded quote is what I said is your opinion, which states that previous dismissal has been "the incorrect solution" and that "it doesn't solve the actual problem". THAT is your opinion.

My opinion is that this isn't a problem to begin with and thus needs no resolution. And you may not like it, you may disagree, but nobody has proven me wrong on this and you better start having some actual arguments before trying to misrepresent what I say and boast about objective facts.
And speaking of that "simple objective fact" ...

There's no way of determining who supplied the header, only the sender has that knowledge.

If my site is only accessible through a proxy (which is the case for Google App Engine sites, sites using CloudFlare with origin pull certificates etc.), and the headers are supplied by the proxy then it is known exactly where the headers came from. Again, this is not simply opinion.

CodeIgniter, PHP, the code, whatever you wish to call it, has not knowledge of this. As far as the technology is concerned, the proxy is the client.
That client may be a proxy or a thousand different things, but it is the direct TCP/IP client - that is an objective fact.

So setup your httpd to replace REMOTE_ADDR with the HTTP_X_FORWARDED_FOR value ... It's a 1-liner in nginx, I can't imagine it being much harder in Apache and others.

It's not a one-liner in Google App Engine and similar platforms. And what you're suggesting is solving a problem outside of CodeIgniter that should be solvable within it.

OK, fine - it may not be a one-liner in GAE (I don't know, I'm just taking your word for it).

I don't give a crap. As far as I'm concerned, if your "problem" stems from GAE putting you behind a proxy, then you should expect GAE to solve it for you. It's not your place to decide what should be "solvable" within CodeIgniter. Again, an opinion.

CodeIgniter even already allows this, but only for one library.

Not "for", but "within".

Different libraries have different purposes. Speaking of which, despite all this big talk about a problem, there's no demonstration of the problem to begin with.
What business do you have looking at addresses in the sessions table? Why would you expect one library's internal data to be tailored for your yet unknown needs?

Not once has this worked for us. You may be savvy enough to deal with such decisions, but I see people making the wrong decisions on a daily basis (not exaggerating even a bit about this).

I sympathise, but leaving CodeIgniter inconsistent is not going to prevent that nor the myriad other things that people can still do wrong with CodeIgniter by ignoring warnings and recommendations; if people ignore warnings, that's on them.

It's not a bug.

CodeIgniter's handling of IP addresses and headers is inconsistent; are you suggesting that that's a feature? Because I certainly wouldn't want to call it that.

Ah, yes ... "Inconsistency" - the universal non-argument argument that everybody falls back to when it suits them. Again, different libraries - different purposes; it's called nuance.

And you need to learn what the term "bug" means. It does not mean something you're not happy with; it means an unintended side effect. The behavior that you're unhappy about is very much intended.

[Haravikk]

You know, I tried to be brief here and leave you room to at least claim a difference of opinion in order to avoid confrontation, but since you're now twisting my words, clearly confrontation is what you're looking for.

No, what I was looking for is for a problem with CodeIgniter to be fixed, or failing that reasoned discussion, but instead you immediately closed the issue with the same dismissive attitude as every other. It's you that seems intent on being confrontational about this subject.

Bolded quote is what I said is your opinion, which states that previous dismissal has been "the incorrect solution" and that "it doesn't solve the actual problem". THAT is your opinion.

You've bolded two very different things:

If you were responding to the part that I myself stated was opinion, just to say that that was my opinion, then why say that at all?

Otherwise you're responding to the part where I point out that what you claim isn't strictly true, which is provably the case, so isn't simply my opinion.

CodeIgniter, PHP, the code, whatever you wish to call it, has not knowledge of this. As far as the technology is concerned, the proxy is the client.

I, and everyone else who has raised this issue, am not asking that PHP or CodeIgniter magically guess whether the connection is safely proxied or not; enabling the feature for the Input library requires CodeIgniter to be specifically configured to handle proxying.

All anyone wants is to be able to do the same thing for the Session library's database driver which is currently inconsistent and based on flawed behaviour.

Proxying is extremely common in web-hosting, so CodeIgniter being unable to handle it properly is a flaw, and it being unable to handle it proper in only some parts of its code is an inconsistency, which most other developers would admit is a bug, as it being intentionally inconsistent is neither advertised nor useful behaviour.

I don't give a crap. As far as I'm concerned, if your "problem" stems from GAE putting you behind a proxy, then you should expect GAE to solve it for you. It's not your place to decide what should be "solvable" within CodeIgniter. Again, an opinion.

The problem IS being solved by GAE, by supplying the correct IP address in the x-Forwarded-For header, and others, as per the HTTP standards on proxying.

CodeIgniter is the component at fault here by failing to provide the means to accept the forwarding headers as trustworthy.

Different libraries have different purposes. Speaking of which, despite all this big talk about a problem, there's no demonstration of the problem to begin with. What business do you have looking at addresses in the sessions table? Why would you expect one library's internal data to be tailored for your yet unknown needs?

Because I would like to actually be able to use the user-IP matching feature for sessions, which simply won't work if every single session has exactly the same IP address. The session library is also wasting space if the entire column is effectively redundant.

It might also be nice to have a sessions table storing IP addresses that are actually accurate so I could actually make use of them, rather than having to setup a parallel table storing the same information just because CodeIgniter's behaviour is incorrect.

Ah, yes ... "Inconsistency" - the universal non-argument argument that everybody falls back to when it suits them. Again, different libraries - different purposes; it's called nuance.

Inconsistency is not a "non-argument", if two pieces of code need an IP address, where one fetches it correctly and the other does so incorrectly, that's a bug, especially if the code to do it correctly already exists and simply isn't being used.

[Haravikk]

For anyone interested in actually solving this, here's the workaround that I'm using:

application/libraries/session/drivers/MY_Session_database_driver.php:

<?php
class MY_Session_database_driver extends CI_Session_database_driver
{
    public function __construct(&$params)
    {
        $CI =& get_instance();
        $_SERVER['REMOTE_ADDR'] = $CI->input->ip_address();
        parent::__construct($params);
    }
}

The above redirects the session database driver towards using the same IP address fetching method as the Input library, so if you're happy to use $config['proxy_ips'] then you can stop here. This template should also work for other drivers.

In my specific case though I went a bit further and bypassed this to directly fetch known headers as follows:

application/core/MY_Input.php:

<?php
class MY_Input extends CI_Input
{
    /// Overrides base ip_address() method to fetch correct IP
    function ip_address()
    {
        if ($this->ip_address !== FALSE)
                {
            return $this->ip_address;
        }

        $CI =& get_instance();
        if ($headers = $CI->config->item('proxy_trusted_ip_headers'))
        {
            foreach ((array)$headers as $header)
            {
                if (($ip = $CI->input->get_request_header($header)) && $this->valid_ip($ip))
                {
                    return $this->ip_address = $ip;
                }
            }
        }

        return parent::ip_address();
    }
}

application/config/config.php (set near the end):

$config['proxy_ips'] = FALSE; // Don't use this
$config['proxy_trusted_ip_headers'] = ['Forwarded-For', 'X-Forwarded-For']; // Tailor for proxy

In my exact case (Google App Engine) I'm using:

$config['proxy_ips'] = FALSE; // Don't use this
$config['proxy_trusted_ip_headers'] = getenv('PROXY_IP_HEADER');

This allows me to pass Google App Engine's header (X-AppEngine-User-IP) via my service's app.yaml file, while defaulting to REMOTE_ADDR in any other environment (e.g- local testing).

Having to override the value of $_SERVER['REMOTE_ADDR'] in the session driver is an absolutely horrible way to do this, but it's the only way to do-so without having to duplicate basically the entire driver.

[narfbg]

If you were responding to the part that I myself stated was opinion, just to say that that was my opinion, then why say that at all?

OK, let's say I wasn't perfectly clear which part I was responding to. What I meant was "you're entitled to your opinion", which is a very common thing to say in a dispute. People will always disagree on something and this is a way to agree to disagree ... I shouldn't have to explain this.

Otherwise you're responding to the part where I point out that what you claim isn't strictly true, which is provably the case, so isn't simply my opinion.

As already explained, that wasn't responding to that, but FFS, stop with that "provably the case". Can you write a test case for it? Can it be mathematically proven? Then it's not "provable".
A judgement call? Applicable under different conditions? Sure, but "provable" means something different.

I, and everyone else who has raised this issue, am not asking that PHP or CodeIgniter magically guess whether the connection is safely proxied or not; enabling the feature for the Input library requires CodeIgniter to be specifically configured to handle proxying.

All anyone wants is to be able to do the same thing for the Session library's database driver which is currently inconsistent and based on flawed behaviour.

First of all, CI_Input has had that feature for longer than I have been involved with CodeIgniter and if it was proposed today, it's very questionable whether it would be accepted. We have a lot of legacy stuff grandfathered in that way and this isn't reason enough to duplicate such features. You're standing on very thin ice with that argument.

Secondly, CI_Input is an input-fetching library and therefore it allowing you to fetch a self-reported address that comes as an input is no surprise, unlike CI_Session, which tracks addresses for security. The fact that the latter doesn't allow you to do dangerous stuff is a sensible choice that anyone knowledgeable about security would recommend, not an inconsistency. Enough said on this; as much as you want to view it as an "inconsistency", the two cases are incomparable and you're being intellectually dishonest for presenting it the way you do.

And finally, stop speaking on behalf of this imaginary crowd that is supposedly pleading with us for this feature. I don't remember a single person having a problem with my explanation that this is done on purpose and isn't an oversight. You're the sole stubborn soul to argue against it and you didn't even have the decency to simply reply to a previous issue about it - no, you had to knowingly create a duplicate so that you can make a big deal out of it and then complain when it inevitably gets closed.

Also, I notice that you consistently refer to the session database driver alone. That seems a bit inconsistent (wink) to me ... You want it only there and users of other drivers can go fuck themselves off?
I'm being cheeky of course, but it does make it seem a lot like you give zero craps about consistency and only care that you get what you want.

Proxying is extremely common in web-hosting, so CodeIgniter being unable to handle it properly is a flaw

There's nothing preventing you from running CI behind a proxy, it doesn't need handling.

and it being unable to handle it proper in only some parts of its code is an inconsistency, which most other developers would admit is a bug, as it being intentionally inconsistent is neither advertised nor useful behaviour.

1. There's no "proper" thing here.
2. Already addressed the "inconsistency" part.
3. A bug is not something one "admits" to. Refer to my previous explanation of what the term "bug" means.
4. You want this behavior to be explicitly "advertised"? Who the hell advertises features that they don't support and that don't naturally exist elsewhere?

The problem IS being solved by GAE, by supplying the correct IP address in the x-Forwarded-For header, and others, as per the HTTP standards on proxying.

I'm not quite sure that such a standard exists to begin with, but that is beside the point and you know perfectly well what I meant.

CodeIgniter is the component at fault here by failing to provide the means to accept the forwarding headers as trustworthy.

I'm done trying to explain to you that things aren't "flawed", "bugs", "inconsistent", "at fault", etc. just because it serves your agenda to call them that way.
Consider it a different POV - CodeIgniter is a framework (not a component of a homogenous system) which doesn't allow you to make a dangerous choice. Everybody wants more freedom in their choices, but unfortunately most can't handle it and here CI is preventing them from shooting themselves in their proverbial foot.

Because I would like to actually be able to use the user-IP matching feature for sessions, which simply won't work if every single session has exactly the same IP address. The session library is also wasting space if the entire column is effectively redundant.

So now we know it's for sess_match_ip. OK, we're making progress here ... Here's why you don't want to use that on a public website:

• kinda useless for users behind a NAT
• countless ISPs will dynamically change IP addresses
• mobile carriers often change addresses on the fly and without your knowledge (there's no modem/router to reset)
• Tor also does that
• Opera's optimizer works by putting you behind a proxy, or rather a pool of proxies, often changing the address seen on the other end (don't know if that still exists though)
• Google Chrome had a similar thing to Opera's at one point

All of the above result in your users being logged out and annoyed. Not your particular crowd you might say, but we do stuff for the masses, not your isolated case.
I myself tried to get a feature like sess_match_ip into PHP and it got rejected ... don't bother trying to argue how it can work - anything you'll come up with I've already thought of myself, presented it before PHP internals and still got shot down because the benefits simply don't outweigh the potential negatives.

What use does sess_match_ip has then? Intranet apps.

You know what's specific about Intranet apps? Not that this is the reason why CI_Session ignores $config['proxy_ips'], but here's what it is - THEY ARE ON YOUR LOCAL NETWORK, ALWAYS HAVE ACCESS TO YOUR LOCAL IP AND DON'T SIT BEHIND A FREAKING PROXY!

As for the column wasting space ... Come on, you're really digging down the well of desperate arguments here.

It might also be nice to have a sessions table storing IP addresses that are actually accurate so I could actually make use of them, rather than having to setup a parallel table storing the same information just because CodeIgniter's behaviour is incorrect.

Make use of them? Parallel table (again, DB-only; perhaps the only data storage that has convenient means of reading the addresses)? I thought you just wanted to use sess_match_ip? This doesn't add up.

You've caught yourself in your own webs dude ... Of course, I knew from the very beginning that you want to access the session data for some other purposes, and you're not saying it because of course that's the easiest to reject use case ever.
Yes, if you want to track IPs for whatever, do setup your own tables.

Inconsistency is not a "non-argument", if two pieces of code need an IP address, where one fetches it correctly and the other does so incorrectly, that's a bug, especially if the code to do it correctly already exists and simply isn't being used.

Yadda, yadda, yadda ... City roads have lower speed limits than country roads, highways have even higher limits; oh no, even different sections of roads have varying speed limits - so many inconsistencies, your head can explode! </sarcasm>

And finally, the workaround that you posted clearly doesn't use $config['proxy_ips'] and it wouldn't ever work with it because of the proprietary headers that you trust (and previously called "standard"), so why the hell did you even come here? Seriously, I've dealt with all kinds of people, but your particular brand of BS is very special.

[Haravikk]

As already explained, that wasn't responding to that, but FFS, stop with that "provably the case". Can you write a test case for it? Can it be mathematically proven? Then it's not "provable".

Basic logic would suffice:

Assertion: Only $_SERVER['REMOTE_ADDR'] can be trusted
Evidence: If a header comes from a trustworthy source, then it can be trusted.
Conclusion: Original assertion is false.

It may be fine as a default, since a user has not configured which header(s) can be trusted and from whom, but that does not make it an absolute in all cases, therefore not strictly true, as I said.

First of all, CI_Input has had that feature for longer than I have been involved with CodeIgniter and if it was proposed today, it's very questionable whether it would be accepted.

That seems more of a condemnation of the current developers; reverse proxying is a common reality in modern web-hosting, while the feature could have been implemented better, it is still necessary for CodeIgniter to actually fetch correct IP addresses.

Secondly, CI_Input is an input-fetching library and therefore it allowing you to fetch a self-reported address that comes as an input is no surprise, unlike CI_Session, which tracks addresses for security. The fact that the latter doesn't allow you to do dangerous stuff is a sensible choice that anyone knowledgeable about security would recommend, not an inconsistency.

You accuse me of hiding behind the word "inconsistency" yet here you are hiding behind the word "security"; you are arguing that it is more correct for CodeIgniter to use the wrong IP address for security purposes.

The only relevant concern for security is whether an IP source is trustworthy; if I have configured CodeIgniter to identify proxies (using the REMOTE_ADDR btw) then I have told it how to identify trustworthy IP address sources. Refusing to use those isn't more secure, it's more limited, these are not the same thing.

Also, I notice that you consistently refer to the session database driver alone. That seems a bit inconsistent (wink) to me ... You want it only there and users of other drivers can go fuck themselves off?

The database driver is the only one I'm using, I have no familiarity with the others; if you want to implement it for all drivers then be my guest.

I'm not quite sure that such a standard exists to begin with, but that is beside the point and you know perfectly well what I meant.

RFC-7239 defines the Forwarded header, as well as providing recommendations on the continued use of X-Forwarded-For etc. Basically Forwarded is the correct way to now do this, but X-Forwarded-For is still widely supported as simpler (it's just a CSV list of IPs, rather than using named parameters).

And no, I apparently don't know what you meant, as you seem to be suggesting that it's not the responsibility of a PHP application to process HTTP requests. GAE has done what a proxy is supposed to do; if an app uses IP addresses then it's up the app to fetch the correct one for what it's doing, not the proxy, and not the web-server (even though most will support doing this one way or another).

In shared hosting environments the website owner often doesn't have access to the web-server settings (or only limited access), you can upload your PHP scripts and other files and that's about it, this has been the case for decades, and GAE is no different in that regard.

Consider it a different POV - CodeIgniter is a framework (not a component of a homogenous system) which doesn't allow you to make a dangerous choice. Everybody wants more freedom in their choices, but unfortunately most can't handle it and here CI is preventing them from shooting themselves in their proverbial foot.

I'm not talking about defaults here, but something that users can (and do) configure, and need to be able to configure; by all means have a sensible default, but you're trying to tell me (the end developer) that I am wrong to want to actually use accurate IP addresses, that's no longer about safety, it's about the framework being limited for what is a flimsy reason.

I know from which sources I can trust forwarding headers, and I have told CodeIgniter this by configuring it accordingly, but part of the framework is simply ignoring that information in order to continue using an incorrect value instead.

So now we know it's for sess_match_ip. OK, we're making progress here ... Here's why you don't want to use that on a public website:
• kinda useless for users behind a NAT

No it's not; the purpose is to invalidate sessions if the IP changes, whether they're behind a NAT or not isn't relevant.

• countless ISPs will dynamically change IP addresses

So the session will be invalidated as expected, and the user asked to login again, or some other mechanism triggered to keep them logged in; since CodeIgniter doesn't support a proper "remember me" feature this is something I've had to do anyway, because I'd rather know when a session ID is suddenly coming from a (potentially) new source and handle it accordingly with additional checks than to trust that I'll somehow magically be fine.

• Opera's optimizer works by putting you behind a proxy, or rather a pool of proxies, often changing the address seen on the other end (don't know if that still exists though)
• Google Chrome had a similar thing to Opera's at one point

And they were both terrible for handling dynamic sites with logins no matter how they were implemented; they were only really suitable for people with slow internet connections or devices who were trying to browse complex sites. There are still similar services but they have much the same limitations.

All of the above result in your users being logged out and annoyed.

This is true of CodeIgniter and PHP's defaults anyway as CodeIgniter's default for cookies is two hours, and PHP's default for sessions is something like 20 minutes (though the way GC works it's probably functionally longer), so you'll be logged out when revisiting any site based on CodeIgniter's default if you come back a few hours later.

Either way to fully implement logins you're either extending these values, in which case tracking IP's accurately becomes more important (to make session theft harder) or you need some other mechanism to log the user back in automatically when the basic session expires.

As for the column wasting space ... Come on, you're really digging down the well of desperate arguments here.

I see, because a column of redundant values serving no purpose whatsoever is the holy-grail of good development? Why not just add the wrong IP address to ALL of my database tables then?

Make use of them? Parallel table (again, DB-only; perhaps the only data storage that has convenient means of reading the addresses)? I thought you just wanted to use sess_match_ip? This doesn't add up.

I want to do both; I'm sorry if you can't conceive of someone wanting to use the correct values for more than one purpose.

And finally, the workaround that you posted clearly doesn't use $config['proxy_ips'] and it wouldn't ever work with it because of the proprietary headers that you trust (and previously called "standard"), so why the hell did you even come here?

It doesn't work with $config['proxy_ips'] because I don't need it to (site is only accessible through a proxy) and I'm using a proprietary header because it's my workaround and I can use whatever fucking header I want, people can tailor it however they like, or not, I didn't say it was a general purpose fix or replacement, because I don't need one for myself.

I could make a proper general purpose change if the only obstacle to inclusion were time, but frankly I see no reason to do-so, as I don't see you accepting any changes no matter what anyway as the key obstacle appears to be your lack of knowledge about the realities of hosting websites.

Seriously, I've dealt with all kinds of people, but your particular brand of BS is very special.

Look in the mirror, buddy; the only thing you've succeeded in doing is convincing me to never use CodeIgniter in another project again, and to rip it out of as many existing ones I reasonably can, as I don't trust your competence as a developer at all, which means I can't trust CodeIgniter either.

[gxgpet]

Hello @Haravikk,

if you will head over php.net, which is the official documentation for PHP, you will notice that there is no occurrence of HTTP_X_FORWARDED_FOR (or anything similar) when speaking about client's IP, but instead, the only place where you can find something related to "the IP address from which the user is viewing the current page" is the $_SERVER docs page, which clearly states what I wrote, being the native way of fetching this piece of information.

Any other header or variable is artificially created by your project's server and infrastructure configuration. This said, you are bound to feed the PHP executable with the proper server variables, including REMOTE_ADDR, especially when you know you are behind a proxy. If you fail to do so, it means that your configuration is either incomplete or wrongly set for PHP to set the REMOTE_ADDR var natively.

Regarding CI_Input's ip_address(), I don't see why would you use that method _unless_ you know you are behind a proxy, since that looks like the main purpose of it; if not, the method will mainly return the REMOTE_ADDR item from $_SERVER. :)

Imagine that the user is using the ip_address() method in the context of the sessions, and it would switch to an environment where there is no proxy. In this case, the value returned by ip_address() would be a perfect candidate for spoofing attacks, and thus, this would defeat the security purpose of using the native way of fetching the IP address.

[Haravikk]

Any other header or variable is artificially created by your project's server and infrastructure configuration. This said, you are bound to feed the PHP executable with the proper server variables, including REMOTE_ADDR, especially when you know you are behind a proxy. If you fail to do so, it means that your configuration is either incomplete or wrongly set for PHP to set the REMOTE_ADDR var natively.

While many can do it, a web-server's job isn't to tell PHP what a user's real IP address is, it's to take an incoming HTTP request and respond or hand it off as fast as possible. In many shared hosting environments, and environments like Google App Engine, you don't have the necessary access to configure proxy IP resolution before a request is handed to PHP for processing, so it needs to be done in PHP code, as the application layer is the only one that actually knows whether you even need the real IP at all.

No general purpose PHP code like CodeIgniter should assume that it is being hosted in an environment where the webmaster can feed it information by any means other than its own configuration files, this is why the $config['proxy_ips'] option will have been added in the first place, as a means of telling CodeIgniter when to examine use proxy headers.

Imagine that the user is using the ip_address() method in the context of the sessions, and it would switch to an environment where there is no proxy. In this case, the value returned by ip_address() would be a perfect candidate for spoofing attacks, and thus, this would defeat the security purpose of using the native way of fetching the IP address.

Actually it wouldn't, as a malicious user would also need to somehow knowingly spoof $_SERVER['REMOTE_ADDR'] in order to match one of the IPs in your $config['proxy_ips'] setting in order for the spoofed header to be used. Even if it were, hypothetically, a problem it isn't really a security issue, but a misconfiguration, and would be no different from copying your proxy IP settings from your Apache or Nginx configuration to a new host without checking them first.

This would be a problem with my full work-around since it bypasses the need for $config['proxy_ips'] in order to use a more convenient, proxy-provided header, except that my environment is generated by a proprietary to GAE app.yaml file so if moved elsewhere the bypass would no longer receive the necessary values and be skipped, reverting back to REMOTE_ADDR.

[gxgpet]

It looks to me that you tangle the concepts over there and I hope that's not deliberately...

While being used primarily as a Web programming language, PHP is a standalone software. You can simply download it and run .php files through it. PHP it's nothing more than an interpreter and executer for PHP code while working within an environment. PHP it's not a network, nor infrastructure manager. It doesn't touch these, it just takes the tailored input from the web server/environment and then it returns the result of code execution. And the input I'm speaking about includes the IP address. If you would run CLI PHP code you will notice that there's no information about the IP at all in the $_SERVER var, because PHP isn't fed with that information. :)

Also, I don't get it when you associate "shared hosting environments" with "Google App Engine" since they are totally different... While shared hosting environments may be limited, they are usually running some ordinary server, and _not_ any load balancers, proxies, etc., so they don't have to worry about who-knows-what headers. Honestly, such a discussion already beats the purpose of this issue and since I can see you are saying that in an environment like Google App Engine you "you don't have the necessary access to configure proxy IP resolution", it looks to me that you are either doing something completely wrong or you are simply using it wrong, and you can't blame CodeIgniter for that...

As for the other part, this has been already discussed: it can introduce security issues based on the environment and this shouldn't be an _option_ or possibility, in my opinion...

[Haravikk]

If you would run CLI PHP code you will notice that there's no information about the IP at all in the $_SERVER var, because PHP isn't fed with that information. :)

PHP's front page:

PHP is a popular general-purpose scripting language that is especially suited to web development.

Meanwhile, right on CodeIgniter's front-page:

CodeIgniter is a powerful PHP framework with a very small footprint, built for developers who need a simple and elegant toolkit to create full-featured web applications.

🤔

Also, I don't get it when you associate "shared hosting environments" with "Google App Engine" since they are totally different...

They really, really aren't. The only real difference between GAE and a "traditional" shared hosting setup is that a GAE app can be spun off into multiple instances, but ultimately your app is still running on a shared pool of hardware. With the increasing use of cloud computing setups like these are only going to become more common, not less.

Even your typical, historic shared hosting setup can be run from behind a reverse proxy such as Cloudflare, some shared hosting providers even provide this as a configurable option.

As for the other part, this has been already discussed: it can introduce security issues based on the environment

Again, this simply isn't true; CodeIgniter's proxy IPs feature requires you to specify the IP address of proxies that you trust, unless a user connects through one of these the feature doesn't activate.

Unless the site operator enters a stupid IP address for this setting this is no more or less secure than not enabling the option, it is also functionally no different to doing this at the web-server level, except that you can't guarantee that a user has access to the necessary options to set this on their web-server, but you can in CodeIgniter, which is why it's the correct place to handle it.

The idea that flawed behaviour is somehow more secure is ridiculous ; without proper proxy support the IP address it stores for a user session is wrong, meaning other security features (match user IP) simply don't function correctly at all. Consider:

h4. Current Behaviour

1. Session is created through proxy configured in $config['proxy_ips'], stored IP address is of proxy.
2. Session is stolen and malicious user connects through same proxy, session is considered valid (not secure, feature entirely useless).

h4. Proposed Behaviour

1. Session is created through proxy configured in $config['proxy_ips'], IP address is from trusted X-Forwarded-For header.
2. Session is stolen and malicious user connects and either:
   
   
   
   1. Malicious user connects via proxy in `$config['proxy_ips']* list and either:
      
      
      
      
      
      1. X-Forwarded-For address matches original session and is accepted (worst case, same as current behaviour)
      
      
      
      2. X-Forwarded-For address does not match and is rejected (more secure)
      
      
      
   
   
   2. Malicious user doesn't connect through proxy in $config['proxy_ips'] (may not even be possible), IP is whatever $_SERVER['REMOTE_ADDR'] contains (user's effective IP or an unconfigured proxy), session is rejected (more secure).
   
   

If the site is transplanted to a new host that isn't behind the same reverse proxy then it will just default to the behaviour in 2.2., i.e- current behaviour. The only way that it might be a security issue would be if you configured a proxy on a private network address and your new host also has a proxy on the same private address but with absolutely no security (passes all headers without modification entirely against how proxies are supposed to work), in which case your problem isn't with your configuration but with a dangerously untrustworthy hosting provider.

Meanwhile, is the match IP feature is disabled, it doesn't matter what IP is used, valid or not, as it's not being used for anything. Though of course it'd still be nice if it were an actual useable value for the database driver as you could actually use it for something else rather than it just being entirely pointless.

[narfbg]

As already explained, that wasn't responding to that, but FFS, stop with that "provably the case". Can you write a test case for it? Can it be mathematically proven? Then it's not "provable".

Basic logic would suffice:

Assertion: Only $_SERVER['REMOTE_ADDR'] can be trusted
Evidence: If a header comes from a trustworthy source, then it can be trusted.
Conclusion: Original assertion is false.

It may be fine as a default, since a user has not configured which header(s) can be trusted and from whom, but that does not make it an absolute in all cases, therefore not strictly true, as I said.

Look man, language and terminology don't just bend to your will. Your basic logic example is not "proof", but yet another assertion. "Proof" is irrefutable, unconditional; it doesn't depend on who or what you trust.
For the Nth time, I didn't even argue against that point of yours, so stop straw-manning it. I'm simply correcting your disingenuous use of words like "provable" and "objective", because you're showing neither of those.

In fact, if you really insist on looking for narrow conditions to satisfy either side of the argument, here's a counterpoint - a malicious actor operating the proxy can alter the reported IP address, thus making it untrustworthy.
Unlikely? Absurd even? Sure, but it weighs just the same as your "not strictly true" case.

First of all, CI_Input has had that feature for longer than I have been involved with CodeIgniter and if it was proposed today, it's very questionable whether it would be accepted.

That seems more of a condemnation of the current developers;

Sure, whatever your majesty says.

reverse proxying is a common reality in modern web-hosting, while the feature could have been implemented better, it is still necessary for CodeIgniter to actually fetch correct IP addresses.

The information is already available in the $_SERVER superglobal, so it isn't even remotely necessary for CodeIgniter to do anything about it.

You accuse me of hiding behind the word "inconsistency" yet here you are hiding behind the word "security";

I'm not accusing you of hiding behind a word; I'm accusing you of being a hypocrite for using arguments that you don't believe in yourself.

you are arguing that it is more correct for CodeIgniter to use the wrong IP address for security purposes.

Once again, you emphasise precisely the one word that you're using incorrectly.

If the HTTP request came from the proxy IP address, then that cannot possibly be the "wrong" IP address to report. Yes, it might be not what you want, but it isn't wrong.
Wrong would be if somehow the server's configured primary DNS IP was returned, for example.

The only relevant concern for security is whether an IP source is trustworthy; if I have configured CodeIgniter to identify proxies (using the REMOTE_ADDR btw) then I have told it how to identify trustworthy IP address sources. Refusing to use those isn't more secure, it's more limited, these are not the same thing.

Security often comes with inherent limitations.

The database driver is the only one I'm using, I have no familiarity with the others; if you want to implement it for all drivers then be my guest.

Yep, so much for your inconsistency argument.

You can't just draw parallels between two completely decoupled libraries, claiming inconsistency, but then give zero fucks about consistency within a single library's subdrivers. You know I never bought this to begin with, just drop it.

RFC-7239 defines the Forwarded header, as well as providing recommendations on the continued use of X-Forwarded-For etc. Basically Forwarded is the correct way to now do this, but X-Forwarded-For is still widely supported as simpler (it's just a CSV list of IPs, rather than using named parameters).

OK, fair enough.

Though, again ... the workaround that you posted uses Proxy-IP-Header and in the same post you refer to X-AppEngine-User-IP, so you saying that GAE is solving your problem and doing so in a "standard" way still appears false.

Still on topic about GAE supposedly solving the problem ...

And no, I apparently don't know what you meant, as you seem to be suggesting that it's not the responsibility of a PHP application to process HTTP requests. GAE has done what a proxy is supposed to do; if an app uses IP addresses then it's up the app to fetch the correct one for what it's doing, not the proxy, and not the web-server (even though most will support doing this one way or another).

So, a PHP application is responsible for processing HTTP requests and it is up to do all the work, but an HTTP server is not?! What? How do you not see a fallacy in this?

And, since you so much insist, what I meant was that since GAE is both hosting your app and putting a proxy in front of it, there's no reason why it shouldn't configure your web server to replace REMOTE_ADDR and make the whole thing transparent to you.
This is what I originally suggested as a solution, hence why I thought it would be clear what I meant.

In shared hosting environments the website owner often doesn't have access to the web-server settings (or only limited access), you can upload your PHP scripts and other files and that's about it, this has been the case for decades, and GAE is no different in that regard.

Shared hosting environments don't force you behind a proxy.

Consider it a different POV - CodeIgniter is a framework (not a component of a homogenous system) which doesn't allow you to make a dangerous choice. Everybody wants more freedom in their choices, but unfortunately most can't handle it and here CI is preventing them from shooting themselves in their proverbial foot.

I'm not talking about defaults here, but something that users can (and do) configure, and need to be able to configure; by all means have a sensible default, but you're trying to tell me (the end developer) that I am wrong to want to actually use accurate IP addresses, that's no longer about safety, it's about the framework being limited for what is a flimsy reason.

I know from which sources I can trust forwarding headers, and I have told CodeIgniter this by configuring it accordingly, but part of the framework is simply ignoring that information in order to continue using an incorrect value instead.

A flimsy reason? Here's four "flimsy" reasons, listed without regards of importance:

• Decoupling; CI_Session should not depend on CI_Input or any other library
• Even if limited to one source, if that source can manipulate security-sensitive data, that is still a vulnerability
• Have you looked at the way CI_Input::ip_address() works? You probably have ... Did you not notice that it simply goes through a list of possible headers to get the IP from? Are you trying to tell me that this is secure and even going further to state that the current CI devs (which, btw, is practically just me) should be condemned for not wanting to accept that?
• sess_match_ip is designed for intranet applications and not what you're trying to do

Regardless of whether you agree or not, after countless arguments (well, mostly counter-arguments to yours) that I've presented, how do you have the nerve to boil it all down to "a flimsy reason"?!

So now we know it's for sess_match_ip. OK, we're making progress here ... Here's why you don't want to use that on a public website:
• kinda useless for users behind a NAT

No it's not; the purpose is to invalidate sessions if the IP changes, whether they're behind a NAT or not isn't relevant.

Invalidating a session for the same legitimate user when his or her IP address changes is nothing but an annoyance for them. That's not the intended purpose.

The goal is to make sure that a third-party (which would logically sit behind a different IP address) can't hijack a session. The more users you have behind a single NAT, the less effective the solution becomes and I've personally seen an ISP put ALL of its users behind a single outbound IP address, so you can imagine it's practically worthless in that case.

• countless ISPs will dynamically change IP addresses

So the session will be invalidated as expected, and the user asked to login again, or some other mechanism triggered to keep them logged in; since CodeIgniter doesn't support a proper "remember me" feature this is something I've had to do anyway, because I'd rather know when a session ID is suddenly coming from a (potentially) new source and handle it accordingly with additional checks than to trust that I'll somehow magically be fine.

You are not everyone.

• Opera's optimizer works by putting you behind a proxy, or rather a pool of proxies, often changing the address seen on the other end (don't know if that still exists though)
• Google Chrome had a similar thing to Opera's at one point

And they were both terrible for handling dynamic sites with logins no matter how they were implemented;

And I agree, but that doesn't change a thing.

they were only really suitable for people with slow internet connections or devices who were trying to browse complex sites.

You're making a very unsubstantiated assertion.

All of the above result in your users being logged out and annoyed.

This is true of CodeIgniter and PHP's defaults anyway as CodeIgniter's default for cookies is two hours, and PHP's default for sessions is something like 20 minutes (though the way GC works it's probably functionally longer), so you'll be logged out when revisiting any site based on CodeIgniter's default if you come back a few hours later.

What? Who's talking about visiting hours later?

The timeout is reset on each subsequent visit; put a continuous ajax polling mechanism of some sort and you can remain logged in indefinitely as long as you keep a tab open. That's not the same thing as being logged out because of a few seconds downtime, or because you're on mobile (which you conveniently left out while replying) and your carrier doesn't provide you with the luxury of keeping the same address between two requests.

Either way to fully implement logins you're either extending these values, in which case tracking IP's accurately becomes more important (to make session theft harder) or you need some other mechanism to log the user back in automatically when the basic session expires.

Again, the whole thing is designed only for intranted apps. It's just not reliable outside of LANs. I wish it was, but it isn't.

As for the column wasting space ... Come on, you're really digging down the well of desperate arguments here.

I see, because a column of redundant values serving no purpose whatsoever is the holy-grail of good development? Why not just add the wrong IP address to ALL of my database tables then?

Really? You can't imagine it's done for convenience? Have you ever written software to be used by more than 10 people?
And I'm not talking about coding convenience; what do you think would happen if someone just decided to switch the option on, even temporarily, and then see an SQL error in response? I'd get bug reports about it at least on a monthly basis. Hell, there's been a few poor souls who've suggested that the table itself be dynamically generated if it doesn't exist yet.

Do I like it? No, but it's a necessary evil and you're almost acting like it's wasting gigabytes of space and/or noticeably slowing everything down, which it clearly isn't.

Make use of them? Parallel table (again, DB-only; perhaps the only data storage that has convenient means of reading the addresses)? I thought you just wanted to use sess_match_ip? This doesn't add up.

I want to do both; I'm sorry if you can't conceive of someone wanting to use the correct values for more than one purpose.

Oh, I can and I suspected it from the very beginning. That's not the point.

I asked you what business you have dealing with internal data structures (meaning stuff you're not supposed to touch) and you intentionally left that part out. The point is, you were being dishonest.

And finally, the workaround that you posted clearly doesn't use $config['proxy_ips'] and it wouldn't ever work with it because of the proprietary headers that you trust (and previously called "standard"), so why the hell did you even come here?

It doesn't work with $config['proxy_ips'] because I don't need it to (site is only accessible through a proxy) and I'm using a proprietary header because it's my workaround and I can use whatever fucking header I want, people can tailor it however they like, or not, I didn't say it was a general purpose fix or replacement, because I don't need one for myself.

Yes, you can use whatever the fuck you want.

However, you said GAE solved your problem in a way defined by HTTP standards, yet your workaround clearly shows it has it's own proprietary solution. This means a few things ...

1. You weren't merely dishonest in order to make your case stronger, you straight up lied.
2. The feature you're so ferociously arguing for clearly can't solve your "problem", so you're wasting everybody's time here.

OR I'm wrong about these 2 points and GAE does indeed populate proper standard headers, but you're intentionally not using the standard solution, yet next thing is you question my competence ...

I could make a proper general purpose change if the only obstacle to inclusion were time, but frankly I see no reason to do-so, as I don't see you accepting any changes no matter what anyway as the key obstacle appears to be your lack of knowledge about the realities of hosting websites.

Seriously, I've dealt with all kinds of people, but your particular brand of BS is very special.

Look in the mirror, buddy; the only thing you've succeeded in doing is convincing me to never use CodeIgniter in another project again, and to rip it out of as many existing ones I reasonably can, as I don't trust your competence as a developer at all, which means I can't trust CodeIgniter either.

Oh no, my competence is being questioned by an angry stranger on the internet who doesn't get what he wants from me. :rofl:

[Haravikk]

Look man, language and terminology don't just bend to your will. Your basic logic example is not "proof", but yet another assertion.

No, it's very basic, very simple logic; whether you can't or won't understand it does not disprove it.

a malicious actor operating the proxy can alter the reported IP address, thus making it untrustworthy.

This doesn't disprove my argument in the slightest; by exactly the same logic a user identified by $_SERVER['REMOTE_ADDR'] could in fact be a virus connecting from an infected computer with the user's knowledge. This assertion is meaningless, and disproves nothing. It is my choice whether to trust a proxy I have either placed before my server, or that is placed before it for me, or are you now trying to show that you don't know what trust means either?

The information is already available in the $_SERVER superglobal, so it isn't even remotely necessary for CodeIgniter to do anything about it.

It is when the data very specifically isn't being used by the part of CodeIgniter in question, which I think even you should be able to grasp.

You can't just draw parallels between two completely decoupled libraries, claiming inconsistency, but then give zero fucks about consistency within a single library's subdrivers.

I reported the issue as I saw it, having only used the database driver; I realise you're scrabbling desperately at nothing to defend your apparent inability to grasp the basics of a simple subject, but this is desperate even for you.

Though, again ... the workaround that you posted uses Proxy-IP-Header and in the same post you refer to X-AppEngine-User-IP, so you saying that GAE is solving your problem and doing so in a "standard" way still appears false.

Thanks for proving you didn't actually bother to pay attention to how my workaround actually works; the first part is the only part that people need to use, and will invoke CI_Input::ip_address() as-is, the rest of the workaround is for using a specific header of your choice. Again, desperately scrabbling at nothing.

So, a PHP application is responsible for processing HTTP requests and it is up to do all the work, but an HTTP server is not?! What? How do you not see a fallacy in this?

No, because that's not what I said at all; the HTTP server's purpose to inspect the minimum amount of a request necessary in order to pass it on or return a static response; everything else is the responsibility of the application onto which the HTTP request is passed.

I think you know this, but if you don't then this is even more embarrassing.

Shared hosting environments don't force you behind a proxy.

Some do, and it's nothing new either, but thanks again for confirming you seem to know nothing about the realities of actually hosting websites from the past 20-30 years.

Decoupling; CI_Session should not depend on CI_Input or any other library

Decoupling alone is not a reason; if CI_Session needs code from CI_Input to function problem then it should be coupled. Decoupling is not a goal in and of itself.

Even if limited to one source, if that source can manipulate security-sensitive data, that is still a vulnerability

No it isn't, because the worst that can be done is for CI_Session to see two different users as the same, or two identical users as different, which it already can't do correctly when all incoming connections are proxied.

Have you looked at the way CI_Input::ip_address() works? You probably have ... Did you not notice that it simply goes through a list of possible headers to get the IP from? Are you trying to tell me that this is secure and even going further to state that the current CI devs (which, btw, is practically just me) should be condemned for not wanting to accept that?

Yes, it is secure, because if a user is setting up $config['proxy_ips'] to enable use of these headers, then they should know whether the proxy/proxies that they enter provide at least one of them. If they don't then they shouldn't be messing with it.

And secondly, why did you think my full workaround includes giving priority to a specific header to use? If it matters so much to you, add the ability to specify which headers CI_Input uses and in what order.

sess_match_ip is designed for intranet applications and not what you're trying to do

That must be it (nor the entire session library documentation) doesn't mention the word "intranet" even once and specifically mentions ISPs, dynamic IPs and other things developers should consider that have nothing to do with intranets. 🤔

sess_match_ip is for matching sessions to the IP that created them; you seem to be inventing conditions for it's use just to claim that I'm wrong to want to use it, even though I have perfectly good reasons to do so and know what I'm doing with it.

Do I like it? No, but it's a necessary evil and you're almost acting like it's wasting gigabytes of space and/or noticeably slowing everything down, which it clearly isn't.

No, I'm pointing out the absurdity of it being a waste of space at all when it could actually be useful (and accurate) in every setup.

I asked you what business you have dealing with internal data structures (meaning stuff you're not supposed to touch) and you intentionally left that part out. The point is, you were being dishonest.

Internal data structures that I have to manually setup, and which exists in my database under a known table and structure and can be trivially queried whenever I like? In a framework that specifically supports overrides of system files?

Yeah sure, it's super unreasonable for me to want to store useful information in my own database. How fearsomely uncivilised of me.

And no, I wasn't being dishonest; again you seem to be scrabbling around desperately for reasons to dismiss the argument rather than honestly address it, it is you who have been dishonest from the start.

However, you said GAE solved your problem in a way defined by HTTP standards, yet your workaround clearly shows it has it's own proprietary solution. This means a few things ...

1. You weren't merely dishonest in order to make your case stronger, you straight up lied.
   The feature you're so ferociously arguing for clearly can't solve your "problem", so you're wasting everybody's time here.
2. OR I'm wrong about these 2 points and GAE does indeed populate proper standard headers, but you're intentionally not using the standard solution, yet next thing is you question my competence ...

Or… GAE provides the standards compliant headers AND it's own proprietary header which I can also choose to use if I want to. You seem to think you're so clever, yet you're apparently not capable of grasping even the most basic of thoughts.

Seriously, if your goal is to prove you have no idea what you're doing, or about the realities of web development, then mission successful.

Oh no, my competence is being questioned by an angry stranger on the internet who doesn't get what he wants from me. 🤣

I haven't failed to get what I want; I have a workaround that works perfectly well for my needs. I'm more just appalled that you consider yourself a web-developer when with every post you expose even further that you seem to know nothing about web-development.

I posted the issue to suggest that a long-standing bug be fixed and why, it was an attempt to give something back, to help improve the framework; your refusing to do-so makes little practical difference to me when I've bypassed the bug, except that I will not be using CodeIgniter for anything in future, as I now know I can't trust any future updates that have you had you anywhere near them, and will move to migrate to another framework in existing projects as soon as I can.

Because I'd rather do extra work to move over to a framework whose developers actually know what they're doing, than continue to use one whose developer has proven he has no clue whatsoever.

[narfbg]

Bahahaha. So now your default answer to everything is that I'm somehow desperate for something and unable to understand anything? Whatever man, I enjoy technical arguments, but I'm not going to dignify this kind of shit throwing with a response.

And do go use whatever else you wish, I insist.

[Haravikk]

So now your default answer to everything is that I'm somehow desperate for something and unable to understand anything?

Of course it is, as that is all that you appear to be demonstrating; you've ignored nearly ever actual point I've made in favour of trying to attack things that have nothing to do with the issue I was raising.

You've tried to question my motives, paint me as dishonest and attack the way I phrased something, rather than what I said, from the outset, add to that inventing arguments based on nothing whatsoever and constantly moving goal posts you yourself have set and if you don't like the conclusions that that leads me to make, then you've only yourself to blame on that one.

Your only actual argument has boiled down to an arbitrary distinction between trustworthy and untrustworthy, but I haven't once asked for the session library to just trust everything unconditionally; by your same logic we can't trust the HTTP server, or the network stack, or the hardware, as literally anything could have been tampered with.

It's not the job of a framework to try to decide which is which, it's to do as the developer told it, as the developer is always in a better position to know what is trustworthy, or what they are willing to trust.

I enjoy technical arguments

All evidence to the contrary, as you've dismissed technical points on increasingly flimsy grounds; what you seem to enjoy is inventing new ways to pretend you're right, rather than being open to the possibility of your being wrong.

I'm not going to dignify this kind of shit throwing with a response.

You literally just did, and did so demonstrating precisely everything I accused you of.

[jim-parry]

Entertaining though this might be, to some, it has gone on long enough.