I don't completely understand the new "Locked" screen, there seems to be 2 uses for it:
1. You won't loose your work when something happens on the server and the app pool recycles. This is perfectly clear to me and a great addition as I've have plenty of complaints from editors that they'd lost an hour's worth of typing.
2. This one I don't get: Why do we get a lock screen after 20 minutes of use (or whatever the timeout setting in the web.config is). This seems to be a security feature, so that people wont hijack your session or something.. But people who NEED this kind of security already have policies set up in their OS right?
So what's the point? Is this really just meant as a sort of security feature or is there something else in there that actually helps editors not loose their work, or is there another reason?
For now, I've just set the umbracoTimeOutInMinutes value to 480 (8 hours) so that it stops bothering me as much (although a app pool recycle could trigger the lock screen to come up again of course).
Although I think it's a nice feature to have it bothers the hell out of me when developing, as every time I compile I'll get the screen. There really should be an option to turn it on/off as needed.
Hmm, I don't think I get it after a compile.. :-) But before this lock screen, did you have to log in after each compile? By the way, just a quick F5 will circumvent the password screen, but you lose your place in the tree of course.
Would be nice if we had an option to turn it off. Also; why does it check every X seconds for 'GetSecondsBeforeUserLogout'? The webservice returns the number of seconds left before logout, so why don't wait the number of seconds the webservice returned and then check again, so you won't have so many ajax calls?
I like this feature very much but I found something what bothers me a lot. I discovered using sql profiler that every 10 seconds when the LOCKED screen is on there is an entry added to umbracoLog table:
Is this a bug? Reported somewhere? Does anybody know how to fix it?
Just imagine (or calculate) that when you leave that interface open in the browser at 6pm (when you finish work) and come back and "unlock" at 9am next day it will flood database with 15h * 60min * 6times per minute = 5400 entries (records) in umbracoLog table and all of this is per user of course!
It doesn't sounds nice, does it?
BTW: I was using FireFox browser if someone would ask :)
What's the purpose of the "Locked" screen
I don't completely understand the new "Locked" screen, there seems to be 2 uses for it:
1. You won't loose your work when something happens on the server and the app pool recycles. This is perfectly clear to me and a great addition as I've have plenty of complaints from editors that they'd lost an hour's worth of typing.
2. This one I don't get: Why do we get a lock screen after 20 minutes of use (or whatever the timeout setting in the web.config is). This seems to be a security feature, so that people wont hijack your session or something.. But people who NEED this kind of security already have policies set up in their OS right?
So what's the point? Is this really just meant as a sort of security feature or is there something else in there that actually helps editors not loose their work, or is there another reason?
For now, I've just set the umbracoTimeOutInMinutes value to 480 (8 hours) so that it stops bothering me as much (although a app pool recycle could trigger the lock screen to come up again of course).
+1
Although I think it's a nice feature to have it bothers the hell out of me when developing, as every time I compile I'll get the screen. There really should be an option to turn it on/off as needed.
Hmm, I don't think I get it after a compile.. :-) But before this lock screen, did you have to log in after each compile? By the way, just a quick F5 will circumvent the password screen, but you lose your place in the tree of course.
The apppool recycles when you compile so that makes sense.
I'll have a look and see what we can do about it.
@Niels
Would be nice if we had an option to turn it off.
Also; why does it check every X seconds for 'GetSecondsBeforeUserLogout'? The webservice returns the number of seconds left before logout, so why don't wait the number of seconds the webservice returned and then check again, so you won't have so many ajax calls?
I like this feature very much but I found something what bothers me a lot. I discovered using sql profiler that every 10 seconds when the LOCKED screen is on there is an entry added to umbracoLog table:
exec sp_executesql N'insert into umbracoLog (userId, nodeId, logHeader, logComment) values (@userId, @nodeId, @logHeader, @comment)',N'@userId int,@nodeId int,@logHeader nvarchar(6),@comment nvarchar(4000)',@userId=0,@nodeId=-1,@logHeader=N'Logout',@comment=N''
Is this a bug? Reported somewhere? Does anybody know how to fix it?
Just imagine (or calculate) that when you leave that interface open in the browser at 6pm (when you finish work) and come back and "unlock" at 9am next day it will flood database with 15h * 60min * 6times per minute = 5400 entries (records) in umbracoLog table and all of this is per user of course!
It doesn't sounds nice, does it?
BTW: I was using FireFox browser if someone would ask :)
The issue with lock screen on compilation is fixed in 4.7 :)
Ah, sweet, thanks for that. :)
Works much better now for us devs.
It still doesn't explain why users need to get logged out after a certain time. I see the technical reason for it, but not the UX reason.
I totally agree with Sascha Wolter. Can't we have some way to turn it off and on?
FYI - in the meantime I think you can use Lee's new Disable BackOffice Timeout package if you are really desperate to disable it :)
is working on a reply...