osTicket Community Forums

Logins fail or time-out too early

osTicket uses sessions to store login information. Unfortunately, most of the settings and code fails in some server setups, especially shared hosting and production environments, because session.save_path is not set to a specific directory.

Fix

Create a directory, e.g. "tmp". Set permissions so that is writable.
In main.inc.php move "session_start();" below the directory constant definitions. Then, before "session_start();" insert
Quick fix for current users

In the root directory of osTicket create a directory "tmp". Change permissions so that it is writable. "chmod 777 tmp" will do but might be a security risk depending on your environment (but if this is of concern for you you should know how to set permissions anyway).
In file main.inc.php before line
insert this:
where "/path/to/osTicket" needs to be your osTicket path/directory, of course.

Fix by means of .htaccess

Gavbond describes how to fix this using .htaccess

I believe this is a wrong approach - osTicket should respect what the sysadmin sets as session path. If it's incorrect then it needs to be fixed system wide - creating a session directory in publicly accessible directly is not the best approach.

Down the road we plan on saving sessions data in the database.

You are the developer. This is your decision. As a user, I don't think there is anything wrong with using options which are available and safe.

However, if you think that the session.save_path setting is up to the server's admin why do osTicket settings include fields for session timeouts etc.? There is no point in evaluating them because the server's admin (e.g. on Debian systems) will have them removed by means of a Cronjob (default setting on many *nix systems) before osTicket will have a chance to evaluate.

No matter what, in the current version 1.6 RC5 this is a bug which does cause confusion and renders parts of the program unusable at least for some users.

What is wrong is putting session directory within the webserver path. What happens if the user has directory listing enabled or session ID shown on url? Yes - session data will be exposed. That is the core of my objection to your fix.

The simple truth is most users are not developers or system admins and might not take the necessary step to protect session data integrity. Session timeouts doesn't affect session data integrity.

I fully understand and I agree with you. My fix is wrong and no solution in this regard. (I did mention it was a security risk.)

ACK. But still, this is a bug in 1.6 RC5 as it is currently delivered in the sense that it is causing problems.

I respectfully disagree that it's a bug. I would rather have the user get the host to set the correct session path in php.ini - than a naive user implementing a fix with security risks packaged with it.

If it was a bug everyone would be having problems - it's only an issue if session path is not configured correctly. It's a server configuration issue not osTicket issue. As I mentioned above we'll change session handling in the future to be self contained.

If you want to change the session save path for your particular installation, that's your prerogative to do so, but respecting the configuration put in place by the system administrator is not a bug, it's responsible programming (It's kind of a First Law thing, except with software and more software, not robots and people).

Yes, there are some instances where this is a better solution, and some instances where the steps you mentioned above (though, well, to be honest, in a much more secure fashion since you're leaving session data wide open to anyone who wants to come in and look at it), would be exactly what that server admin would recommend. However, those instances should be evaluated on a case-by-case basis, by someone who is familiar with the specifics of the particular server configuration and the security issues involved.

To tell people to do this with wild abandon is just reckless and irresponsible.

This only effects a handful of installations and is due to a discrepancy in configuration on the server, not a bug in the software.

Good luck!

This bug report has been classified as "Not a Bug". As long as this is the case I will probably see some sort of denial, indeed.

I have no rights to change the code base. I can offer my help. I can open a bug report. I can suggest a fix. It is up to you to evaluate and see how it fits.

Yes, the original posting of my bug report might not be a complete fix. It might not be sufficiently secure for some or many, however it sure is for some.

Nevertheless, again, I state that the session management is not working as it is intended and advertised. Again, I think that while no new version is released, setting the session.save_path is an option and a fix to consider. The security implications are rather easy to fix.

But I don't see much point in offering more help if the main developers are not welcoming it.

Dude, give it a rest, really.

No one said it wasn't an issue.

No one said changing the session save path wasn't an option.

No one said it wasn't warranted, or in fact, the best solution, in some cases.

In fact, if you'll read my reply, I said all of those things, and Peter also acknowledged, before that, that it is an issue that can occur on some configurations.

The only person in denial here is you.

But that does not make it a bug and it does not mean the system is broken or needs a magical "fix."

Session handling works great on a properly configured server.

On a locked-down or misconfigured server, OK there might be issues, but one would assume that if it is that locked down, it is done for a reason, and therefore the software needs to respect that. If that means that osTicket won't run on that server, then so be it. That's the server administrator's prerogative to impose those restrictions and you can take it up with them or work around it yourself. If the server isn't properly configured, then that's the server admin's problem, not osTicket's.

Yes, you can work around it with the fix you mentioned above, and if you wanted to post that as a mod for people having this issue, then fine, go for it.

But don't go making accusations, calling it something it isn't and plastering the forum with your holier-than-thou attitude whenever you disagree. That's really not the way to get your concerns addressed.

If you need to make the change to get it to work on your particular configuration, then fine, go for it.

But telling everyone to do it or making it a required part of the osTicket setup? No. It isn't necessary and the security risks just aren't worth the trade-off.

Really, I'm done. It's like talking to a brick wall.

I classified it as "Not a Bug" because it's not - to me it is a feature request. As I mentioned we plan on adding db based session management in the future.

My take is you took it personal when I indicated that it wasn't a bug and the proposed solution posed potential security risk to some users. You might be a very technical osTicket user but in my experience many are not and won't take necessary steps to secure their installation.

We welcome help but it's also our responsibility to make sure the code is shipped relatively secure.

Just to be clear Kelli is referring to this thread - http://osticket.com/forums/showthread.php?t=3439

Well I had the same issues since I installed osTicket. I believe I have resolved my issues. I am behind a firewall that changes IP addresses at random. It is the way my ISP does it. Well in the /include/class.usersession.php at around line 94 the script does an arbitrary check that IP address has not changed. The code is:

I commented this out and now I am working just fine.

There should be a config switch that allows this to be turned off for some people.

I hope this helps others.

It's sort of a completely separate issue, but one we will be resolving with in the next update. We'd been aware of it for some time.

Thanks for the feedback.

Hey slvolz, Thanks for posting this. I was able to solve a problem we had for months been behind ISA firewall. Thanks a lot!! worked like a charm. Hope OSticket project keep moving forward and patching these issues. Never understood as a code myself the need for actual the script to have that much level of built in security into it or an option to turn it off. This was not in place as far as I know in previous version since the problem surfaced after update to RC5.

@codex73 osTicet v1.6 stable due out this week will have an option to turn off IP binding.

Sounds Good Peter!

Sorry shouldn't have posted this here.
Moved to
http://osticket.com/forums/showthrea...6195#post16195

I used what I learnt in this thread to create my own spin on a solution.