*puff*
I am in the same boat... Please help.
I am having the same problem. My workaround was to remove the <asp:loginstatus> control from the <updatepanel> By doing this, the loginstatus control will cause a postback outside of Atlas and, thus, successfully set the context.user.identity.isauthenticated to FALSE.
BTW, if our webpartmanager is also wrapped in an Atlas Update panel, we have found that we are unable to move web parts. I've only done testing with the Update Panel on the master page, but I am going to do further testing by wrapping the content in an update panel, wrapping a standalone page in an update panel, and, finally, wrapping just the webparts in an update panel.
chapzilla:
... My workaround was to remove the <asp:loginstatus> control from the <updatepanel> ...
Unfortunately that does not seem to do it for me. I have my loginstatus in the master page and I have no update panel there at all. Also I don't understand what the loginstatus has to do with it? The redirect on isauthenticated False thing is set in the web.config and does not require a loginstatus, right? Or did I miss something...
Anyone who does _not_ have this problem?
Just to follow up on my original post. This is a very frustrating issue. We have implemented a workaround. It is not perfect by any means, but I will describe it here in case it helps anyone.
In summary we run javascript when an Atlas call is started to record the value of a timestampt from within the panel, X seconds later if the timestamp has not been updated we trigger a full postback which will result in a redirect (assuming the session has expired).
In more detail:
When a button inside the panel is clicked, in addition to the normal Atlas call to the server, we run some javascript to record the value of a timestamp field shown in the panel. Then we set off a timer (Atlas client based) for X seconds (say 10 seconds). If all is well the Atlas call should return and the contents of the page (including the timestamp) should be updated. When the timer expires we check to see if the timestamp has changed. If it has changed then all is well. If it has not changed then it is most likely due to the session expiring in which case we perform a full postback (document.forms[0].submit()) and this results in a nice redirect to login.
In addition to this we have a 15 minute timer running on the client, each time this expires we trigger a full postback. That serves 2 purposes. Firstly it will generally keep the session alive. Secondly if the session has expired (for example if the web application has restarted on the server) it will result in the user being redirected to login.
This mechanism works for buttons in the panel, but we have not been able to put the same mechanism into a gridview on the same panel.
I have still not seen any response from the Atlas team on this issue (other than it will be looked at). When will a fix be coming?
I am sure that other people must have worked around this problem. Has anyone got a better workaround since this is a lot of work to make Atlas usable.
Moderators,
Do you have any ideas when this bug will be fixed? I'm having the same problem and is eager to know if there's a solution insight.
hello guys.
from what i've seen, fixing this will make them re-write their network stack classes since this happens when authorization module checks the session cookie and redirects it to another page. currently, the client side doesn't understand the response it gets from the module.
i think that writting a new authorizationmodule will solve this problem, though i haven't tried it...
This is just too bad
If I can't get a decent work-around I'll have to remove Atlas from my site.
Hai, I'm also encounter the same problem. I Figure-out some ways to fix this, but because I'm new in ASP.NET so I encounter some obstacle that I still don't know how to solve it.
Basicly, I create a timer on the client side using javascript:
<script language="javascript" type="text/javascript">
<!--
var timer;
function SessionStart(timeout) {
clearTimeout(timer);
timer = setTimeout("SessionExpired", timeout);
}
function SessionExpired()
{
alert("Your session already expires, please re-login");
document.location.href = "Login.aspx";
}
//-->
</script>
then inside the asp:
<atlas:updatepanel ...>
<contenttemplate>
<literal ID="_startTimer" runat="server" />
:
<contenttemplate>
<triggers>
:
</triggers>
</atlas:updatepanel
using code-behind, then we fill the literal Text property with the javascript that call theSessionStart method and passing asp'sSession.TimeOut value as it parameter.
This will working fine, after certain period the message box will appear, and when the user dismiss the message box it will be redirected to the Login.aspx page.
Unfortunatelly, during postback of the updatepanel, somehow, the javascript that I put inside the literal didn't re-called by the browser.
The idea is, everytime the updatepanel refreshed (meaning an activity still exists), we should re-call theSessionStart function that will cancel the last timer, and re-initiate a new timer.
Crossing on my mind that I'll try to add tag attribute like "OnClick" in each control that cause the postback/updatepanel refresh, so each time that control clicked/executed, it will re-call theSessionStart function, but still don't have time to explore on these possibilities.
Regards,
Lok
hnseu,
Our solution is to capture session expirations in the Page_Load event. We check on some session variable, and if it has expired, we make sure we are signed out and then just redirect to the main page. Forms authentication should send the user to the login page, and when they sign in, they get back to the default page. It's a little cleaner than playing with timers and javascript.
if (CheckSessionObjectExists() == false){
FormsAuthentication.SignOut();
Response.Redirect("~");
return;
}
hello.
are you sure this works?
Luis,
I hope so. We're using it in a production environment.
hello again.
let's suppose i'm using forms authentication and i've set the permissions on several of the resources (pages) of my app. looking at the urlauthorizationmodule, i see that it handles the authorizerequest event which comes before the instantiation of the handler. if this is the case, your page will never be instantiated and the code you've written won't be run...
I agree with Luis and this is exactly why this is such a problem to resolve. If the session has expired the attempt to redirect occurs, the page never loads/runs on the server and the client just consumes the redirect and terminates the Atlas call.
The page will not run if the session has expired. The forms authentication is doing exactly what it should be doing by preventing the page from running and redirecting to Login. It is just that the Atlas implementation does not respond as it should.
For now the workaround I described above has been put into production on our server and to date we have not had any reports of any problems. It is far too complicated though and it is not a complete workaround. I can't wait to get rid of it.
Does anyone have any idea when the Atlas team might produce a fix? Is there a release schedule anywhere?
No comments:
Post a Comment