Welcome Guest, Not a member yet? Register   Sign In
Session randomly disappear
#1
Sad 

Hi,

We are using Code Igniter 2.2 on one of our internal website and it has grow very large now. For a long time it has been working fine with the exception of sessions got destroyed randomly. It is a small problem to us as we are all programmers here but soon we will be rolling the system to everybody in the company which includes a lot of less nerdy people so this session bug will become an issue.

I learnt that upgrading to 3.x will fix the problem but that will be a huge project to us and given the framework has no other issues other than this we would like to avoid upgrading it as much as possible. 

I have tried a lot of suggestions on the internet including setting the time out to a specific number (cant remember what was the magic number now but it didnt work anyways), set time out to 0, set $sess_expiration in Session.php to a supper large number, setting $cookie_secure to false, commenting out the whole session_destroy() function in Session.php...

Im just wondering if there is a patch or walk around that we can apply instead of upgrading as we are very happy about the framework as it is right now.

Thanks in advance.
Reply
#2

Hmm "We are all programmers" and in the next line you state that upgrading will (probably) fix your issue but you won't do it because it's a 'huge' project...

"The framework has no other issues", well the fact that 2.x version has been 'End of life' for almost 1.5 years should be considered a major issue.

Ffs, if you are expending your project, do the upgrade before adding more stuff to it.
Reply
#3

(01-16-2017, 12:09 AM)[email protected] Wrote: I learnt that upgrading to 3.x will fix the problem but that will be a huge project to us and given the framework has no other issues other than this we would like to avoid upgrading it as much as possible. 

It has a number of security vulnerabilities.
The 3.0.0 changelog contains hundreds of bugfixes against 2.x.
If it didn't have issues, new versions wouldn't be released.
Reply
#4

(01-16-2017, 01:52 AM)Diederik Wrote: Hmm "We are all programmers" and in the next line you state that upgrading will (probably) fix your issue but you won't do it because it's a 'huge' project...

"The framework has no other issues", well the fact that 2.x version has been 'End of life' for almost 1.5 years should be considered a major issue.

Ffs, if you are expending your project, do the upgrade before adding more stuff to it.

Well, the fact that we got 10 programmers here doesn't mean we got nothing to do everyday. We tend to be busy and constantly short on hands. If we can do it without making too many changes, it is a good thing right? What happened to a lazy programmer is a good programmer. From a business perspective, Im looking at potentially 100 lines of changes across 3 files (just an estimate) vs 100+ changes across 40+ files and load of time doing testing, i would pick the former on any day.

End of life means they do not support it anymore. If we can fix this issue without upgrading it we do not need anymore support, so we are perfectly fine with this version being at end of life.

Considering the cost of upgrading it, i see no harm in asking before i proceed to a more costly action.
Reply
#5

(01-16-2017, 02:40 AM)Narf Wrote:
(01-16-2017, 12:09 AM)[email protected] Wrote: I learnt that upgrading to 3.x will fix the problem but that will be a huge project to us and given the framework has no other issues other than this we would like to avoid upgrading it as much as possible. 

It has a number of security vulnerabilities.
The 3.0.0 changelog contains hundreds of bugfixes against 2.x.
If it didn't have issues, new versions wouldn't be released.

Hi Narf, i agree with you on "If it didn't have issues, new versions wouldn't be released.". But the fact that we are still using this version despite this version which was at its end of life 1.5 years ago means this is a rather stable version and we are happy with it. Other problems this framework has either doesn't affect us or concern us. 

As a programer I understand it is a good practice to keep the framework up to date and im all up for it if i got the time and resources; but at the same time i have to consider the cost of my decisions and all the alternatives.
Reply
#6

(01-16-2017, 03:24 PM)[email protected] Wrote:
(01-16-2017, 02:40 AM)Narf Wrote:
(01-16-2017, 12:09 AM)[email protected] Wrote: I learnt that upgrading to 3.x will fix the problem but that will be a huge project to us and given the framework has no other issues other than this we would like to avoid upgrading it as much as possible. 

It has a number of security vulnerabilities.
The 3.0.0 changelog contains hundreds of bugfixes against 2.x.
If it didn't have issues, new versions wouldn't be released.

Hi Narf, i agree with you on "If it didn't have issues, new versions wouldn't be released.". But the fact that we are still using this version despite this version which was at its end of life 1.5 years ago means this is a rather stable version and we are happy with it. Other problems this framework has either doesn't affect us or concern us. 

As a programer I understand it is a good practice to keep the framework up to date and im all up for it if i got the time and resources; but at the same time i have to consider the cost of my decisions and all the alternatives.

You've cherry-picked the most banal part of my comment to argue against, and that is simply because you're looking for a reason to avoid upgrading.

There's a 99% chance that at least one of the security flaws fixed in more recent versions affect your application(s), so I wouldn't wave-off that part as easy as you're doing.
And if CI_Session is your immediate issue ... The 2.x version is fundamentally broken, and rewriting it was a major part of the work towards 3.0. Knowing all the issues it had, I'm almost certain that you don't have a developer capable of "fixing" it; and if you did - it would take them much more effort than it would to simply upgrade.

Depending on your application size and how skilled your developers are, it may take up to 8 hours to upgrade, which you've already spent waiting for non-existent solutions here. Some people on this forum have done it in less than an hour.

Plus, don't underestimate the political/social effects of your decision - no developer wants to work on an outdated project, let alone one that's been deliberately kept that way. The last time I left a job, it was exactly because of this.
Reply
#7

(This post was last modified: 01-16-2017, 05:10 PM by PaulD. Edit Reason: typo )

(01-16-2017, 03:14 PM)[email protected] Wrote: Well, the fact that we got 10 programmers here doesn't mean we got nothing to do everyday. We tend to be busy and constantly short on hands. If we can do it without making too many changes, it is a good thing right? What happened to a lazy programmer is a good programmer.

But there have been 'security' improvements, meaning your site is now insecure. Part of owning or managing a site is to keep your users secure. If your framework is out of date for security patches you are not providing the service your users expect. Even if you have a site without users, then you still have the problem that your webserver could be hijacked in some way.

Upgrading is usually relatively simple, except when there are BC breaking changes, which are well documented and again usually fairly easy to implement.

"What happened to a lazy programmer is a good programmer." - Really! Seriously? A lazy programmer should be fired. I want hard working, committed and serious programmers, not lazy, short cut taking, security careless, don't give a damn just cutting my workload programmers.

Sounds to me like your firefighting rather than fulfilling a planned pathway of development. Perhaps you could save money in the long run if you employed less lazy programmers and invested some time in planning your software development cycles (and stopped hacking away with a buggy unsupported version and instead took full advantage of all the improvements the hard work and commitment the CI team has done for you).

EDIT PS Narfs reply above arrived while I was writing this. And as always he makes a much better reply than I did.
Reply
#8

(01-16-2017, 04:55 PM)Narf Wrote:
(01-16-2017, 03:24 PM)[email protected] Wrote:
(01-16-2017, 02:40 AM)Narf Wrote:
(01-16-2017, 12:09 AM)[email protected] Wrote: I learnt that upgrading to 3.x will fix the problem but that will be a huge project to us and given the framework has no other issues other than this we would like to avoid upgrading it as much as possible. 

It has a number of security vulnerabilities.
The 3.0.0 changelog contains hundreds of bugfixes against 2.x.
If it didn't have issues, new versions wouldn't be released.

Hi Narf, i agree with you on "If it didn't have issues, new versions wouldn't be released.". But the fact that we are still using this version despite this version which was at its end of life 1.5 years ago means this is a rather stable version and we are happy with it. Other problems this framework has either doesn't affect us or concern us. 

As a programer I understand it is a good practice to keep the framework up to date and im all up for it if i got the time and resources; but at the same time i have to consider the cost of my decisions and all the alternatives.

You've cherry-picked the most banal part of my comment to argue against, and that is simply because you're looking for a reason to avoid upgrading.

There's a 99% chance that at least one of the security flaws fixed in more recent versions affect your application(s), so I wouldn't wave-off that part as easy as you're doing.
And if CI_Session is your immediate issue ... The 2.x version is fundamentally broken, and rewriting it was a major part of the work towards 3.0. Knowing all the issues it had, I'm almost certain that you don't have a developer capable of "fixing" it; and if you did - it would take them much more effort than it would to simply upgrade.

Depending on your application size and how skilled your developers are, it may take up to 8 hours to upgrade, which you've already spent waiting for non-existent solutions here. Some people on this forum have done it in less than an hour.

Plus, don't underestimate the political/social effects of your decision - no developer wants to work on an outdated project, let alone one that's been deliberately kept that way. The last time I left a job, it was exactly because of this.

Hi Narf, Im not trying to start an argument here. I dont mind waiting as we got quite a lot of works here to do while we wait. I just thought it would be nice if i can avoid upgrading thats all im saying. 
I understand that 3.x is better than 2.x but as far as the scope of our project goes, we dont want to spend time on the things that we dont need just to follow good coding practice. That is how business runs, not based on good coding practice but on needs. I do battle for more resources whenever i see a chance so we can finish projects properly but that kind of luxury can not be expected all the time.
Reply
#9

(01-16-2017, 05:01 PM)PaulD Wrote:
(01-16-2017, 03:14 PM)[email protected] Wrote: Well, the fact that we got 10 programmers here doesn't mean we got nothing to do everyday. We tend to be busy and constantly short on hands. If we can do it without making too many changes, it is a good thing right? What happened to a lazy programmer is a good programmer.

But there have been 'security' improvements, meaning your site is now insecure. Part of owning or managing a site is to keep your users secure. If your framework is out of date for security patches you are not providing the service your users expect. Even if you have a site without users, then you still have the problem that your webserver could be hijacked in some way.

Upgrading is usually relatively simple, except when there are BC breaking changes, which are well documented and again usually fairly easy to implement.

"What happened to a lazy programmer is a good programmer." - Really! Seriously? A lazy programmer should be fired. I want hard working, committed and serious programmers, not lazy, short cut taking, security careless, don't give a damn just cutting my workload programmers.

Sounds to me like your firefighting rather than fulfilling a planned pathway of development. Perhaps you could save money in the long run if you employed less lazy programmers and invested some time in planning your software development cycles (and stopped hacking away with a buggy unsupported version and instead took full advantage of all the improvements the hard work and commitment the CI team has done for you).

EDIT PS Narfs reply above arrived while I was writing this. And as always he makes a much better reply than I did.

lol, lazy programmer is good programmer is a saying, it came from the original author of Perl, Larry Wall, "...three great virtues of a programmer; Laziness, Impatience and Hubris".
This is going to go off topic but I understand all the salt from you guys as i was like that for quite a few years. Im all up for good practice and Im fully aware of what are the benefits Im losing by not upgrading it and I will take the consequences. Im just here to ask if there is a quick fix for it. I will be appreciated if there is one and someone can point it out for me instead of attacking my question.
Reply
#10

I think you overestimate the work it takes to perform the upgrade. My largest project took about 4 hours.

I understand laziness can be considered a good quality of a programmer, but not in the way you explain it or tend to use the term. Because I am lazy I will spend lots of time to automate as much as possible in my work flow. Figuring out smart solutions not cut corners, thats what Larry Wall meant ;-)
Reply




Theme © iAndrew 2016 - Forum software by © MyBB