Session expired, text lost
Hi,
Ocassionally it happens that the OTRS login session expires while a
support question is being answered. When clicking on "Send Mail", the
mail is not sent but rather the login screen is presented. After logging
in, the view is at the support ticket, but the written answer is lost
for good.
Using the back button of the browser to get back to the reply and copy
it is an option, but not really a nice one. I am not sure whether I can
improve the situation by modifying some config file, but don't think so.
I'd be happy about any pointers on how to improve this situation
(extended timeout?), as this is a problem that can really be annoying
(like if one just put a LOT of thought into a reply ... ;-))
--
Daniel Seifert
One helpful thing might be to increase the session timeout. see http://doc.otrs.org/1.2/en/html/configfile-session.html On Thu, 18 Mar 2004, Daniel Seifert wrote:
Hi,
Ocassionally it happens that the OTRS login session expires while a support question is being answered. When clicking on "Send Mail", the mail is not sent but rather the login screen is presented. After logging in, the view is at the support ticket, but the written answer is lost for good.
Using the back button of the browser to get back to the reply and copy it is an option, but not really a nice one. I am not sure whether I can improve the situation by modifying some config file, but don't think so. I'd be happy about any pointers on how to improve this situation (extended timeout?), as this is a problem that can really be annoying (like if one just put a LOT of thought into a reply ... ;-))
Am Fr, den 19.03.2004 schrieb Steven Shults um 00:53: Hi,
One helpful thing might be to increase the session timeout.
Yes, but this just delays the problem, doesn't it?
It may be okay in cases where OTRS is only checked during office hours
(8-5) to set it to 12 hours, because even if someone logs in only
shortly before 5pm, the expiration will be before he gets back next
morning. Unfortunately this does not really work here as we may check
the OTRS later in the evening, too, if there wasn't enough time before.
--
Daniel Seifert
On Friday, March 19, 2004 7:48 AM
Daniel Seifert
One helpful thing might be to increase the session timeout. Yes, but this just delays the problem, doesn't it? It may be okay in cases where OTRS is only checked during office hours (8-5) to set it to 12 hours, because even if someone logs in only shortly before 5pm, the expiration will be before he gets back next morning. Unfortunately this does not really work here as we may check the OTRS later in the evening, too, if there wasn't enough time before.
Are you really composing messages and leave the browser open when you go home? You shouldn't do. When work is finished, the agent should log off. Increasing the session time means the agent has more time from his last action onwards, not from the beginning of his logon. In other words: If you allow a 12h session, an agent logging in at 5 pm and performing the most recent action at, say, 8 pm may do nothing for 12h from 8 pm on, so he's safe till 8 am next morning - not 5 am. hth, Robert Kehl -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388
Am Fr, den 19.03.2004 schrieb Robert Kehl um 15:28: Hi,
Are you really composing messages and leave the browser open when you go home? You shouldn't do. When work is finished, the agent should log off.
I don't. It expires WHILE I am writing a reply so that I have to re-login as soon as I hit "Send Mail". A colleague of mine has complained about this, too. He usually comes at 8:30am and leaves before 5pm.
Increasing the session time means the agent has more time from his last action onwards, not from the beginning of his logon. In other words: If you allow a 12h session, an agent logging in at 5 pm and performing the most recent action at, say, 8 pm may do nothing for 12h from 8 pm on, so he's safe till 8 am next morning - not 5 am.
Are you sure about this? My log says otherwise.
Checking the logs, my OTRS day had the following relevant events
yesterday:
Mar 18 07:59:28 zire OTRS-CGI-10[26148]: [Notice][Kernel::System::Auth::DB::Auth] User: dseifert logged in
Mar 18 15:02:26 zire OTRS-CGI-10[370]: [Notice][Kernel::System::Ticket::SendArticle::SendArticle] Sent email ... HistoryType => SendAnswer ...
at some time after 3pm I started answering a new ticket which
was rather tricky, I was also disturbed by several phone calls.
Considering the next line of the log, I was clicking on "Send
mail" at ~5:25pm:
Mar 18 17:25:16 zire OTRS-CGI-10[370]: [Notice][Kernel::System::AuthSession::IPC::CheckSessionID] SessionID (10e33ce8653a21e6b3471097c8a9bf137d) too old (8h)! Don't grant access!!!
Mar 18 17:25:16 zire OTRS-CGI-10[370]: [Notice][Kernel::System::AuthSession::IPC::RemoveSessionID] Removed SessionID 10e33ce8653a21e6b3471097c8a9bf137d.
Mar 18 17:25:23 zire OTRS-CGI-10[32715]: [Notice][Kernel::System::Auth::DB::Auth] User: dseifert logged in (REMOTE_ADDR: 192.168.1.1).
192.168.1.1, btw, is the proxy server.
I have a timeout of 8 hours, I was kicked out 9:25 hours after I logged
in, less than 2:23 hours after I replied to the last ticket and
presumably at least a few minutes less after I started answering the
next ticket.
For me it definitely looks like the session timeout applies to the start
of the session, but not to the last action (because this was at 3pm so
the session shouldn't have expired before 11pm).
--
Daniel Seifert
On Friday, March 19, 2004 7:15 PM
Daniel Seifert
Are you really composing messages and leave the browser open when you go home? You shouldn't do. When work is finished, the agent should log off.
I don't. It expires WHILE I am writing a reply so that I have to re-login as soon as I hit "Send Mail". A colleague of mine has complained about this, too. He usually comes at 8:30am and leaves before 5pm.
Nice job times ;) But where is his problem then with an 8h session time? Should be enough up to a few minutes.
Increasing the session time means the agent has more time from his Are you sure about this? My log says otherwise.
Sorry. I expected it to work that way, because that's one way of how sessions can be used. In fact, we don't use them that way, my apologizes. I can't tell you why we're using that kind of session management, as it's outside my focus. So you should be able to solve your problem by setting the session tim to a much higher value than 8h. Regards, Robert Kehl -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388
Am Fr, den 19.03.2004 schrieb Robert Kehl um 19:55: Hi,
I don't. It expires WHILE I am writing a reply so that I have to re-login as soon as I hit "Send Mail". A colleague of mine has complained about this, too. He usually comes at 8:30am and leaves before 5pm.
Nice job times ;) But where is his problem then with an 8h session time? Should be enough up to a few minutes.
For him, yes. But I'm a bit more egoistic :-) My working hours are quite irregular and I may be answering emails between 7am and 11pm (14 hour span), depending on the day, etc etc.
So you should be able to solve your problem by setting the session time to a much higher value than 8h.
I can't think of a timeout value that does guarantee that it will never
expire while I'm actually in front of the PC, because I may login at so
many different times with no prediction.
I will increase the timeout to 12 hours, though, as this will cover many
cases.
But this was not the point. I don't mind to re-login every few hours ,
that's ok with me. I'm just not sure that forgetting about a message is
the perfect solution for any software solution.
Here's how I would fancy the situation:
* Daniel answers a ticket
* Daniel clicks on "Send Mail"
* OTRS sees that the session has expired in the meantime
* Daniel has to login
* OTRS goes back to message compose view and has REMEMBERED what
Daniel has written previously [1]
Like I said, I don't mind to relogin. But I seriously mind to lose a
mail I have just written. The probability that it's been a long email or
one where one has put considerable thought into is quite high. Usually
going back in the browser and copying the text works. Usually.
--
Daniel Seifert
participants (3)
-
Daniel Seifert -
Robert Kehl -
Steven Shults