Problems, need help? Have a tip or advice? Post it here.
4 posts Page 1 of 1
Hello,

I have a problem with users being "logged in" for long periods of time.

I set up sort of a ticketing system where users can send various requests to change their shifts (plus time, minus time, doctors appointment etc), which can then be approved/denied by a teamleader or staff planners.

When a user opens the main index.php, the Apache server fetches the visitors NT-User from the AD controller. The NT-User is then checked against a list of staff planners and teamleaders and redirected accordingly (index_staffplanner or index_teamleader). If the user is in neither list, he gets redirected to index_user).

Take note that the users are just checked against an editable list of NT-Usernames. not against actual couch users. In fact, the only existing couch user is the main superadmin account.

At first I had an issue with users bookmarking the index_user page directly (because they would skip the "get the current NTUser" script and would show up as "empty" users. However, I managed to solve this by redirecting the visitor to the main index site if the user cookie was empty. This works like a charm now.

However, not all users reset their PC daily and most of them just keep the page open. The page itself refreshes every 60 seconds. However, when a user has been logged on for a long time (I think it's 24 hours), there are two problems:

1) If he creates a new ticket (which uses databound forms) and hits submit, the Security tokens do not tally for executing this action error gets thrown.

2) Status on existing tickets aren't updated properly (even after hitting F5 - an already denied ticket eg would still show up as "open" for the user (status display is basically a simple <cms:show status /> for each ticket (each ticket is a cloned page). This is especially baffling to me and might be an unrelated caching issue. However, opening the proper index.php fixed the problem.

My question now is: can I somehow tell couch to redirect back to index.php if the the security token has expired, or can I disable the function alltogether and allow databound forms to be submitted no matter what?
When a databound-form is first displayed, it has a security token attached that is valid for the next 24 hours.
When this form is filled and submitted, the security token is returned along with the posted data as a security measure to prevent the dreaded CSRF vulnerabilities.

You'll get the 'token do not tally' only if the period between the time the form was served by the web-server and the time it was returned back exceeds 24 hours.

Please consider the following workflow - a user wishes to submit a ticket, she presses a button 'Open ticket', the server is contacted and a form is served (with a 24 hour token). She fills the form and submits it back.

There should hardly be an issue with the workflow described above because it is unlikely that the user will take more than 24 hours to fill and send back the form she requested above.

Now consider the following workflow -
the user opens her profile page and it has (of other things) a form (with the 24 hr token) that can be filled and submitted to create the ticket. It will, of course, work but now there is every chance that the user will just keep the profile page open and decide anytime to fill the form and submit it. It is now very easy to overshoot the 24 hour mark.

I suspect the page you have created resembles the second workflow above.
If it is, you'll need to modify the workflow in a way that a form is not served unless explicitly requested (e.g. by pressing a button 'Open ticket'). Perhaps it'd also be a good idea to display the form in a modal box.

By doing that you'll drastically decrease the chances of the user happening to submit a stale form.

Please let me know if this makes sense.
Hi there,

yeah my workflow more closely resembles the 2nd example (all of the page is loaded at once and i use cycle.js to make different pages - so as soon as the page is loaded, the databound form is loaded aswell.

While on the main "subpage", the entire page refreshes every 60 seconds, however if a user is on the archive sub-page, or even the submit ticket page itself, the autorefresh gets disabled.

I have now implemented a forced refresh after 8 hours no matter what, this should hopefully fix the problems :)
Sorry for the double post, but I now have two new problems with this error:

The first one I already described in another post here: viewtopic.php?f=4&t=11247

The second one seems especially crazy to me:

As I already described in my other post, I am listing the contents of cloned pages in a table (with each row being a page). Here is a screenshot for easier understanding:

Image

If the dropdown is changed or an ok checkbox is checked, a "save" button appears in the last column for that row.

Clicking it submits a databound form that edits the existing page. This works as intended.

In this view, only the pages where the ok checkbox is not checked is shownl (using custom field filtering).

If between page load (page refreshes every 60 seconds) and submitting via the save button, the number of shown tickets changes, I get the "Security Tokens do not tally for executing this action" error.

So e.g. user A loads the page, and waits for like 30 seconds and then checks the ok box on the third row and then hits save, but during these 30 seconds user B hit the checkbox on the first row and submitted, then user A will get the error.

It only happens if the number of shown pages changes. If in above example user B only changes the dropdown value to something else, so that the page is still shown, and user A hits save, it will work as expected.

Is there ANY way to turn off the security tokens error alltogether? The page is only accessible from the intranet so I'm not that concerned about security issues.

I found the exact problem now! More testing revealed that it wasn't so much a change of shown pages, but the incremental form name count. It seems that if you have multiple cloned pages which are also databound forms, couch automatically assigns name=kformnameN wheras n is an increasing number from 0 upwards.

By simply ensuring that a forms name stays unique, the problem gets solved (I just added name="<cms:show 'ticketedit' /><cms:show k_page_id />" to the databound forms).
4 posts Page 1 of 1
cron