People and Tasks lists on dashboard ajax-loads sign in page if user logged out

This also affects the Task list

You knows, dozens of widgets have this in the Content:

(#(header:Location: [root]/users/sign_in|false|301)#)

Really though I feel like this should only exist on pages with specific URLs.

I think what to do is that if the user session times out, then just automatically reload the sign in screen. Don't wait for users to click something and find out they are no longer logged in!

Then remove these redirects from sub-widgets.

On a few widgets (like People list) I've been removing the redirect because now that People can sign in they need to see it too (more exactly a different version).

The original reason for including the redirect was to force the use to sign back in if they are interacting with the widget. But that was never a good solution to begin with.

Again - if the user session expires, he should just be logged out. He shouldn't have to attempt to interact with the interface before he discovers this.

Simply removing the redirects from lower level ajax widgets and finding a better solution to the entire problem (user session has expired) would fix this bug.

The tasks list still has this problem. If you are logged out and click Start on one of the tasks, the sign-in page is loaded into the profile_container div.

Where is the session length set? It's way to short for PPL, by a factor of 100 to 1000.

it's set in config.php
$config["session_timeout"] = 7200;
this value is in milliseconds you can change it to much higher number

What about forcing a sign out after the timeout is reached, redirect to the sign in page?

Brad we should take a look at some lower level widgets and ask, does this really need a redirect rule or is no output sufficient if the session has expired.

Another current behavior of the Dashboard people list:

1) An owner is logged in and viewing the dashboard. The People list displays his or her contacts.

2) The owner's session expires.

3) The owner tries to paginate the People list using the Next or Previous buttons.

WHAT ACTUALLY HAPPENS:

* The People list will load the publicly available contents of the People list which is a list of Public Profiles.

WHAT SHOULD HAPPEN

* The Owner should be redirected to the sign-in page.

I have no idea how to fix this. It seems that the globalajaxify stuff that makes the links inside the dashboard more attractive by refreshing widgets is also preventing the outermost dashboard_container widget from recognizing that a link has been clicked by a user that isn't authorized.

As a temporary fix, I've tried to fight jquery with jquery by adding some rules to the sign-in widget that check to see if the widget has been loaded within a dashboard element (either the 'view-details' 2nd column or the 'dummy_search_results_container' in the first column). Depending on which widget it has been loaded in, it will remove all of the dashboard elements that and add classes that style it in the same way as the sign_in page.

The result is basically the /dashboard page changing to appear as the /users/sign_in page, if a user's session has timed out & they try interacting on the page.

So, the scenarios that are now fixed include:

1. Clicking on a task item or a contact after a session has expired
2. Clicking the pagination links below the people-list after a session has expired.

The new javascript doesn't affect the regular users/sign-in page because of the conditionals that are in place. Please try this & let me know what you all think.

Actually, the 3rd scenario where user's try & perform a contact search & delete the search is fixed as well. As soon as a query is deleted, the jquery kicks in & turns the /dashboard into the sign-in page.

This kind of works, but there's as yet to style to the sign-up page which appears on the dashboard. Also, since the endpoint is no longer users/sign_in, it would seem the browser doesn't pre-fill your username or remember your password (at least on my system).

Ideally we still want to redirect to users/sign_in.

Does anyone else have proposals?

Right, so I was thinking about this some more, and my jquery instruction that checks to see if the sign_in widget is loaded within other widgets is a good start. Instead of removing other elements on the page, why don't I just refresh the page?

So, the code has been cut by 75% by replacing all the .remove() & .addClass() instructions with one instance of:

location.reload();

Refreshing the page causes the dashboard_container widget to send the user back to the /users/sign_in page, so it's no longer faking the page.

Christopher, can you confirm & mark this as fixed, if you think the solution is enough?