|
Author
|
Message
|
|
David Wirth
|
Thursday 06 May 2010 1:10:34 pm
Desired behavior:
- Anonymous user attempts to navigate to mysite.com/abc but that section is restricted to users of a certain user group, so error module executes and presents login.tpl to user.
- User logs in successfully, has necessary view permission.
- User is redirected to mysite/abc (rather than to some statically defined redirect target, like the mysite.com root).
This seems like it should be a commonly desired behavior and thus easy to accomplish, but apparently not. I have gathered that kernel/error/view.php puts the login template output into the module result but so far I cannot figure out if the requested URI gets passed in any way to login.tpl and if so how to access it. I could pull it from the session but It looks like the LastAccessesURI variable does not get set to the requested page if the user does not have permission to view the node in question. I came up with a bunk workaround -- javascript in the pagelayout passes the requested URI back to the RedirectURI hidden element -- but I'm thinking there must be a better solution. Do I have to write a custom error/view module? Or is there a reason I should not be trying to redirect to the requested URI?
|
|
Gaetano Giunta
|
Thursday 06 May 2010 2:09:52 pm
I might be missing something here, but the behavior you describe is exactly the default one...
Principal Consultant International Business
Member of the Community Project Board
|
|
David Wirth
|
Friday 07 May 2010 6:20:46 am
"
I might be missing something here, but the behavior you describe is exactly the default one...
"
I had a lengthy response written out about how the default behavior was the undesirable behavior I previously described but decided before posting I ought to take a look at design/standard/templates/user/login.tpl, and boy howdy was I surprised to see that you are correct. Our ez instance was created and modified by a subcontractor before I started working on it and I guess I just assumed they would not have altered the default, desired behavior to produce the undesirable behavior we have now. I am corresponding with the subcontractor to see what their thinking was on this. Unless they give me a good reason (as in maybe they discovered that the default behavior can somehow produce infinite looping), I'll just undo their redirect modification and mark this thread resolved. Thanks.
|
|
David Wirth
|
Friday 07 May 2010 7:39:03 am
Yeah, turns out there was a misunderstanding about a requirement -- it was the logout behavior that was supposed to be modified to use the LastAccessesURI entry. So, um, happy Friday, I guess. Carry on.
|
|
Gaetano Giunta
|
Friday 07 May 2010 12:59:59 pm
A dirty little secret: the RedirectOnLogoutWithLastAccessURI setting in site.ini file might be enough to get the desired behaviour upon logout, too, with no need to alter templates adding redirects
Principal Consultant International Business
Member of the Community Project Board
|
|
David Wirth
|
Monday 10 May 2010 5:19:24 am
Thanks. After testing it. I've realized that the subcontractor chose not to use that feature because the LastAccessesURI for our main page ends up getting set to the node of a flash component in the page, so when you log out, instead of going back to the main page you get a generic view of the flash component node. I do not yet know how this flash component works but am looking into it. Meanwhile, is there a way to override logout behavior for a single node? Extension?
|
