Nevow - 'connection lost' javascript alert on page reloads
I have even tried with the HEAD revision from subversion of Nevow, but the problem still persists! On page reloads (on loads), I get this javascript alert "The connection to the remote server was lost. The page may fail to work correctly. Reloading the page may fix the problem." Looking at liveevil.js if (xmlhttp.responseText) { connect(outputNum + 1) eval(xmlhttp.responseText) } else { alert('The connection to the remote server was lost. The page may fail to work correctly. Reloading the page may fix the problem.'); } xmlhttp.responseText is null !! It is supposed to be null only connection problems. So isn't this a bug? Here is the project that uses Nevow and gets the above problem http://svn.berlios.de/viewcvs/codehack/trunk/ Nevow code is kept under trunk/lib/codehack/server/ Service code is at trunk/lib/codehack/server/gateway.py .tac is here trunk/startserver.tac -- Sridhar R - http://cs.annauniv.edu/~rsridhar Blog: http://www.livejournal.com/~sridharinfinity
I have even tried with the HEAD revision from subversion of Nevow, but the problem still persists!
On page reloads (on loads), I get this javascript alert "The connection to the remote server was lost. The page may fail to work correctly. Reloading the page may fix the problem."
Looking at liveevil.js if (xmlhttp.responseText) { connect(outputNum + 1) eval(xmlhttp.responseText) } else { alert('The connection to the remote server was lost. The page may fail to work correctly. Reloading the page may fix the problem.'); }
xmlhttp.responseText is null !! It is supposed to be null only connection problems.
In theory it is a connection problem. By leaving the current page the browser shuts down all connections created by the page including the liveevil connection. (You get the same message with Mozilla/Firefox by merely hitting <Esc>.) Nevow needs a robust way of detecting when the liveevil connection is legitimately closed as opposed to real errors, i.e. the server disappearing. I played around with the liveevil javascript for a couple of hours one evening. It's easy enough to make liveevil reconnect when the XMLHttpRequest's socket object is closed but I could not find a way to determine the cause of the shutdown. That makes handling errors gracefully quite difficult. If anyone knows how to handle XMLHttpRequest errors then please post here and we'll get a fix into Nevow. Cheers, Matt -- __ / \__ Matt Goodall, Pollenation Internet Ltd \__/ \ w: http://www.pollenation.net __/ \__/ e: matt@pollenation.net / \__/ \ t: +44 (0)113 2252500 \__/ \__/ / \ Any views expressed are my own and do not necessarily \__/ reflect the views of my employer.
On Wed, 10 Nov 2004 20:01:12 -0000 (GMT), Matt Goodall <matt@pollenation.net> wrote:
If anyone knows how to handle XMLHttpRequest errors then please post here and we'll get a fix into Nevow.
k3mper has provided a patch. I tried it and it works! somebody needs to merge this patch with HEAD. http://divmod.org/users/roundup.twistd/nevow/issue131 And when is nevow-0.3.1? (0.3.1 with the above patch?) -- Sridhar R - http://cs.annauniv.edu/~rsridhar Blog: http://www.livejournal.com/~sridharinfinity
On Nov 10, 2004, at 8:24 PM, Sridhar R wrote:
On Wed, 10 Nov 2004 20:01:12 -0000 (GMT), Matt Goodall <matt@pollenation.net> wrote:
If anyone knows how to handle XMLHttpRequest errors then please post here and we'll get a fix into Nevow.
k3mper has provided a patch. I tried it and it works! somebody needs to merge this patch with HEAD. http://divmod.org/users/roundup.twistd/nevow/issue131
Applied, thank you very much k3mper. And thank you Sridhar for testing it.
And when is nevow-0.3.1? (0.3.1 with the above patch?)
I'd probably rather just release nevow 0.4 with more changes. Sometime in the next month would be nice. Does anyone have suggestions for what 0.4 should have? The big thing I am planning is the use of zope.interfaces to get rid of all the deprecation warnings when you use Nevow with twisted SVN Head (and thus 2.0) dp
Donovan Preston wrote:
I'd probably rather just release nevow 0.4 with more changes. Sometime in the next month would be nice. Does anyone have suggestions for what 0.4 should have? The big thing I am planning is the use of zope.interfaces to get rid of all the deprecation warnings when you use Nevow with twisted SVN Head (and thus 2.0)
My current open pet peeves: http://divmod.org/users/roundup.twistd/nevow/issue132 [PATCH] twisted.trial.util no longer has _getDeferredResult http://divmod.org/users/roundup.twistd/nevow/issue122 [PATCH] Guard adds a cookie with path='/', does not ever set secure. http://divmod.org/users/roundup.twistd/nevow/issue120 Release procedure is SNAFU, e.g. no LICENSE or ChangeLog in tarball Also, I would love to hear whether the following items from sandbox/tv please you: access Simple access control for web requests. branchsecure Resource wrapper that shows different resources based on whether the connection was secure or not. reversemonster Reverse proxy the request, assuming the other end is a VHostMonsterResource. Extremely easy to configure, automagic hostname, port and path passing. (for some overviewish things, see sandbox/tv/trac, especially the dia file)
And when is nevow-0.3.1? (0.3.1 with the above patch?)
I'd probably rather just release nevow 0.4 with more changes. Sometime in the next month would be nice. Does anyone have suggestions for what 0.4 should have? The big thing I am planning is the use of zope.interfaces to get rid of all the deprecation warnings when you use Nevow with twisted SVN Head (and thus 2.0)
dp
On my wishlist: * Sort out the url module and add new deprecation warnings ;-). * Finish and merge the unicode forms stuff. * Kill the evil overloaded render method signature hack and simplify parameterised render and data methods. * Apply/fix any easy/significant issues in the tracker. * Documentation. Cheers, Matt -- Matt Goodall, Pollenation Internet Ltd w: http://www.pollenation.net e: matt@pollenation.net
On Thu, 11 Nov 2004 12:31:30 -0800, Donovan Preston <dp@ulaluma.com> wrote:
On Nov 10, 2004, at 8:24 PM, Sridhar R wrote:
And when is nevow-0.3.1? (0.3.1 with the above patch?)
I'd probably rather just release nevow 0.4 with more changes. Sometime in the next month would be nice. Does anyone have suggestions for what 0.4 should have? The big thing I am planning is the use of zope.interfaces to get rid of all the deprecation warnings when you use Nevow with twisted SVN Head (and thus 2.0)
I have some suggestions. 1. The exception stack trace sent to HTTP client is more colorful and verbose. May be you could use javascript to make the code segments of each trace point collapsable/expandable (I mean collapse to see only that *line* in stack trace and expand to see the surrounding lines) 2. Allow for multple logins (guard) from same host (This would help in testing Nevow applications which involves multiple accounts in the same machine). Well, actually I am quite biased, the only URL of my app is http://localhost:8080 (though I have different rend.Page classes derived from common one). May be one could have http://localhost:8080/user1 and http://localhost:8080/user1 and so on for different users. Even then (I have not tested it), I am not sure whether guard allows such authorization (cookie mess?) -- Sridhar R - http://cs.annauniv.edu/~rsridhar Blog: http://www.livejournal.com/~sridharinfinity
Sridhar R wrote:
2. Allow for multple logins (guard) from same host (This would help in testing Nevow applications which involves multiple accounts in the same machine). Well, actually I am quite biased, the only URL of my app is http://localhost:8080 (though I have different rend.Page classes derived from common one). May be one could have http://localhost:8080/user1 and http://localhost:8080/user1 and so on for different users. Even then (I have not tested it), I am not sure whether guard allows such authorization (cookie mess?)
Run two different instances of the browser. Profiles with mozilla will help.
Tommi Virtanen wrote:
2. Allow for multple logins (guard) from same host (This would help in testing Nevow applications which involves multiple accounts in the same machine). Well, actually I am quite biased, the only URL of my app is http://localhost:8080 (though I have different rend.Page classes derived from common one). May be one could have http://localhost:8080/user1 and http://localhost:8080/user1 and so on for different users. Even then (I have not tested it), I am not sure whether guard allows such authorization (cookie mess?)
Run two different instances of the browser. Profiles with mozilla will help.
Or, alternatively, deny cookies and use path-based sessions.
I have imitated the login process as shown in the nevow example guarded.tac. A couple of questions: 1) After I log in, the username and password are shown in the address bar. Is there anyway to force the guard code to use post instead of get so that such things are not displayed so publicly. I tried changing the main log-in form to use post, but it seems there is a redirect that occurs that prevents such a change from having the desired result. 2) I would like to check the up address that the user is logging in from to perform some additional verification. Is there a way to get access to this information in Realm.requestAvatar or in CredentialsChecker.requestAvatarId, or somewhere else where it may be incorporated into the log-in process? Thanks, Alex
Alexander May wrote:
1) After I log in, the username and password are shown in the address bar. Is there anyway to force the guard code to use post instead of get so that such things are not displayed so publicly. I tried changing the main log-in form to use post, but it seems there is a redirect that occurs that prevents such a change from having the desired result.
That's a bug in _your_ code. Just use POST. Guard doesn't implement the form. From guarded.tac: tags.form(action=guard.LOGIN_AVATAR, method='post')[
2) I would like to check the up address that the user is logging in from to perform some additional verification. Is there a way to get access to this information in Realm.requestAvatar or in CredentialsChecker.requestAvatarId, or somewhere else where it may be incorporated into the log-in process?
Well, you can do it before or after the guard, atleast. http://divmod.org/svn/Nevow/sandbox/tv/access
That's a bug in _your_ code. Just use POST. Guard doesn't implement the form. From guarded.tac:
tags.form(action=guard.LOGIN_AVATAR, method='post')[
I was working off the 0.3 examples directory which does not have method=post. Somewhat baffled I looked at the version in the svn trunk and I see that the example has been updated to include method=post. It works (as you know); I'm glad to see the guard code handles it correctly. Thanks.
Well, you can do it before or after the guard, atleast.
If I parse this code correctly, you are simply pulling the ipaddress and url out of the context passed to various resource functions and filtering on it. I certainly could do this as well, but I would prefer to have access to it while I have an avatar available too. Furthermore I would like to create a single log entry of avatar and ip-address for every log-in. Doing it a web page centric way strikes me as less good then doing it in a log-in centric way. Alex -----Original Message----- From: twisted-web-bounces@twistedmatrix.com [mailto:twisted-web-bounces@twistedmatrix.com] On Behalf Of Tommi Virtanen Sent: Tuesday, November 16, 2004 4:15 AM To: Discussion of twisted.web, Nevow,and Woven Subject: Re: [Twisted-web] Credential questions - hide user name and passwordon login + get ip address in realm Alexander May wrote:
1) After I log in, the username and password are shown in the address bar. Is there anyway to force the guard code to use post instead of get so that such things are not displayed so publicly. I tried changing the main log-in form to use post, but it seems there is a redirect that occurs that prevents such a change from having the desired result.
That's a bug in _your_ code. Just use POST. Guard doesn't implement the form. From guarded.tac: tags.form(action=guard.LOGIN_AVATAR, method='post')[
2) I would like to check the up address that the user is logging in from to perform some additional verification. Is there a way to get access to this information in Realm.requestAvatar or in CredentialsChecker.requestAvatarId, or somewhere else where it may be incorporated into the log-in process?
Well, you can do it before or after the guard, atleast. http://divmod.org/svn/Nevow/sandbox/tv/access _______________________________________________ Twisted-web mailing list Twisted-web@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
On Tue, Nov 16, 2004 at 09:42:05AM -0500, Alexander May wrote:
That's a bug in _your_ code. Just use POST. Guard doesn't implement the form. From guarded.tac:
tags.form(action=guard.LOGIN_AVATAR, method='post')[
I was working off the 0.3 examples directory which does not have method=post. Somewhat baffled I looked at the version in the svn trunk and I see that the example has been updated to include method=post. It works (as you know); I'm glad to see the guard code handles it correctly. Thanks.
Yes, that was me -- I saw, after your post, that one guard example had a POST method, and one did not. I also updated userdb.tac. -- Alex Levy WWW: http://mesozoic.geecs.org/ "Never let your sense of morals prevent you from doing what is right." -- Salvor Hardin, Isaac Asimov's _Foundation_
That's a bug in _your_ code. Just use POST. Guard doesn't implement the
Also, while on I'm on the subject of guard, is there a way to set the url a user reaches after log in? For example if the log in form is at http:/foo.com/, I would like the admin log in to end up at http:/foo.com/Admin/, and the non admin log in to end up at http:/foo.com/Home/. Currently, both just end up at the root url. Should the respective resources returned in Realm:requestAvatar just do a redirect, or is some simple way to rewrite the url? I tried muddling with the various path members of the request in locateChild with no success. -----Original Message----- From: twisted-web-bounces@twistedmatrix.com [mailto:twisted-web-bounces@twistedmatrix.com] On Behalf Of Alexander May Sent: Tuesday, November 16, 2004 9:42 AM To: 'Discussion of twisted.web, Nevow,and Woven' Subject: RE: [Twisted-web] Credential questions - hide user name andpasswordon login + get ip address in realm form.
From guarded.tac:
tags.form(action=guard.LOGIN_AVATAR, method='post')[
I was working off the 0.3 examples directory which does not have method=post. Somewhat baffled I looked at the version in the svn trunk and I see that the example has been updated to include method=post. It works (as you know); I'm glad to see the guard code handles it correctly. Thanks.
Well, you can do it before or after the guard, atleast.
If I parse this code correctly, you are simply pulling the ipaddress and url out of the context passed to various resource functions and filtering on it. I certainly could do this as well, but I would prefer to have access to it while I have an avatar available too. Furthermore I would like to create a single log entry of avatar and ip-address for every log-in. Doing it a web page centric way strikes me as less good then doing it in a log-in centric way. Alex -----Original Message----- From: twisted-web-bounces@twistedmatrix.com [mailto:twisted-web-bounces@twistedmatrix.com] On Behalf Of Tommi Virtanen Sent: Tuesday, November 16, 2004 4:15 AM To: Discussion of twisted.web, Nevow,and Woven Subject: Re: [Twisted-web] Credential questions - hide user name and passwordon login + get ip address in realm Alexander May wrote:
1) After I log in, the username and password are shown in the address bar. Is there anyway to force the guard code to use post instead of get so that such things are not displayed so publicly. I tried changing the main log-in form to use post, but it seems there is a redirect that occurs that prevents such a change from having the desired result.
That's a bug in _your_ code. Just use POST. Guard doesn't implement the form. From guarded.tac: tags.form(action=guard.LOGIN_AVATAR, method='post')[
2) I would like to check the up address that the user is logging in from to perform some additional verification. Is there a way to get access to this information in Realm.requestAvatar or in CredentialsChecker.requestAvatarId, or somewhere else where it may be incorporated into the log-in process?
Well, you can do it before or after the guard, atleast. http://divmod.org/svn/Nevow/sandbox/tv/access _______________________________________________ Twisted-web mailing list Twisted-web@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web _______________________________________________ Twisted-web mailing list Twisted-web@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
On Nov 16, 2004, at 7:50 AM, Alexander May wrote:
Also, while on I'm on the subject of guard, is there a way to set the url a user reaches after log in? For example if the log in form is at http:/foo.com/, I would like the admin log in to end up at http:/foo.com/Admin/, and the non admin log in to end up at http:/foo.com/Home/. Currently, both just end up at the root url. Should the respective resources returned in Realm:requestAvatar just do a redirect, or is some simple way to rewrite the url? I tried muddling with the various path members of the request in locateChild with no success.
The path segments which appear after the __login__ segment in the login form you generate will be used as the target of the redirect after login. Unfortunately this doesn't solve your problem, because you want to redirect based on the type of login. Perhaps the resource you return as / can immediately do a redirect to the appropriate URL? For example: class Redirector: __implements__ = inevow.IResource, def __init__(self, avatar): self.avatar = avatar def calculateAppropriateRedirectURL(self): if self.avatar.admin: return '/Admin/' return '/Home/' def locateChild(self, ctx, segments): return self, () def renderHTTP(self, ctx): inevow.IRequest(ctx).redirect(self.calculateAppropriateRedirectURL()) Perhaps also this redirect would only happen once, and set some state on self indicating it happened, and then do a normal page render if the user visited / after the first time. dp
participants (7)
-
Alex Levy -
Alexander May -
Donovan Preston -
Donovan Preston -
Matt Goodall -
Sridhar R -
Tommi Virtanen