Fatal Flaw in my Web App!
Locked
 
|
I just discovered a fatal flaw in my web app. By chance, I was looking
at the PostgreSQL database for my app, which uses GLORP. When I did the following in PSQL: SELECT * FROM PG_STAT_ACTIVITY; I discovered much to my horror that the DB connections from previous logins/logouts were still lingering around. I had assumed that they'd timeout and go away. When I logout, I do a session expire, and I thought this takes care of all GLORP issues. Apparently, I was dead wrong! Is there a nice easy way for me to solve this without doing major surgery to my web app? At the time of logout (or even Seaside session timeout), I do not necessarily have access to the GLORP instance variables. Thanks, Richard _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Fatal Flaw in my Web App!
|
|
I usually store my glorp session on the seaside session, and upon
expiring, it sends logout to the glorp session. This has the dual benefit of the above, and having easy accessor to glorp in the form of: self session glorpSession anywhere in my Tasks/Components. John Richard Eng wrote: > I just discovered a fatal flaw in my web app. By chance, I was looking > at the PostgreSQL database for my app, which uses GLORP. When I did the > following in PSQL: > > SELECT * FROM PG_STAT_ACTIVITY; > > I discovered much to my horror that the DB connections from previous > logins/logouts were still lingering around. I had assumed that they'd > timeout and go away. When I logout, I do a session expire, and I thought > this takes care of all GLORP issues. Apparently, I was dead wrong! > > Is there a nice easy way for me to solve this without doing major > surgery to my web app? At the time of logout (or even Seaside session > timeout), I do not necessarily have access to the GLORP instance variables. > > Thanks, > Richard > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > -- John Thornborrow http://www.pinesoft.co.uk ****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Richard Eng
I have a puzzling problem. I've made some changes to do what you suggest.
I've subclassed WASession: WASession subclass: #GSSession ...with instance variable #database. I've created #unregistered as follows: unregistered database ifNotNil: [database logout]. super unregistered I've put the following in #GSRegistrationLogin (my root component for the app): self application preferenceAt: #sessionClass put: GSSession And when the user logs out, the following is executed: html anchor callback: [self session expire]; with: [html paragraph style: 'color: red'; with: [html strong: 'Logout']] But the #unregistered doesn't always get executed. Sometimes, not at all! And sometimes, much later, as in the *next* time I login and logout (?!). What am I doing wrong?!! Shouldn't session expiry *always* cause #unregistered to execute? Thanks, Richard ---------------- John wrote: I usually store my glorp session on the seaside session, and upon expiring, it sends logout to the glorp session. This has the dual benefit of the above, and having easy accessor to glorp in the form of: self session glorpSession anywhere in my Tasks/Components. John _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: Fatal Flaw in my Web App!
|
|
Hi Richard,
I'm overriding #expire in a custom session class to free resources (like persistence sessions). cheers, Sebastian Sastre > -----Mensaje original----- > De: [hidden email] > [mailto:[hidden email]] En nombre > de Richard K Eng > Enviado el: Viernes, 23 de Mayo de 2008 16:31 > Para: Seaside - general discussion > Asunto: Re: [Seaside] Fatal Flaw in my Web App! > > I have a puzzling problem. I've made some changes to do what > you suggest. > I've subclassed WASession: > > WASession subclass: #GSSession > > ...with instance variable #database. I've created > #unregistered as follows: > > unregistered > database ifNotNil: [database logout]. > super unregistered > > I've put the following in #GSRegistrationLogin (my root > component for the > app): > > self application preferenceAt: #sessionClass put: GSSession > > And when the user logs out, the following is executed: > > html anchor > callback: [self session expire]; > with: [html paragraph style: 'color: red'; with: > [html strong: > 'Logout']] > > But the #unregistered doesn't always get executed. Sometimes, > not at all! > And sometimes, much later, as in the *next* time I login and > logout (?!). > What am I doing wrong?!! Shouldn't session expiry *always* cause > #unregistered to execute? > > Thanks, > Richard > > ---------------- > John wrote: > > I usually store my glorp session on the seaside session, and upon > expiring, it sends logout to the glorp session. > > This has the dual benefit of the above, and having easy accessor to > glorp in the form of: > > self session glorpSession > > anywhere in my Tasks/Components. > > John > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: Fatal Flaw in my Web App!
|
|
In reply to this post by Richard Eng
See,
WARegistry>>shouldCollectHandlers Cheers, -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. > -----Original Message----- > From: [hidden email] [mailto:seaside- > [hidden email]] On Behalf Of Richard K Eng > Sent: Friday, May 23, 2008 12:31 PM > To: Seaside - general discussion > Subject: Re: [Seaside] Fatal Flaw in my Web App! > > I have a puzzling problem. I've made some changes to do what you suggest. > I've subclassed WASession: > > WASession subclass: #GSSession > > ...with instance variable #database. I've created #unregistered as > follows: > > unregistered > database ifNotNil: [database logout]. > super unregistered > > I've put the following in #GSRegistrationLogin (my root component for > app): > > self application preferenceAt: #sessionClass put: GSSession > > And when the user logs out, the following is executed: > > html anchor > callback: [self session expire]; > with: [html paragraph style: 'color: red'; with: [html strong: > 'Logout']] > > But the #unregistered doesn't always get executed. Sometimes, not at > And sometimes, much later, as in the *next* time I login and logout (?!). > What am I doing wrong?!! Shouldn't session expiry *always* cause > #unregistered to execute? > > Thanks, > Richard > > ---------------- > John wrote: > > I usually store my glorp session on the seaside session, and upon > expiring, it sends logout to the glorp session. > > This has the dual benefit of the above, and having easy accessor to > glorp in the form of: > > self session glorpSession > > anywhere in my Tasks/Components. > > John > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Richard Eng
"Oh, I see!" said the blind man as he picked up his hammer and saw. From the
Seaside.st FAQ: >From time to time, Seaside processes expired sessions (see #unregisterExpiredHandlers). Expired sessions are removed from Seaside, making them candidates for future garbage collections, then they are sent #unregistered. The standard implementation of #unregistered in WASession is empty. #unregistered is sent *when garbage collection is done*. It's not necessarily executed immediately. I should've read the FAQ more carefully. Richard ----- Original Message ----- From: "Richard K Eng" <[hidden email]> To: "Seaside - general discussion" <[hidden email]> Sent: Friday, May 23, 2008 3:31 PM Subject: Re: [Seaside] Fatal Flaw in my Web App! >I have a puzzling problem. I've made some changes to do what you suggest. >I've subclassed WASession: > > WASession subclass: #GSSession > > ...with instance variable #database. I've created #unregistered as > follows: > > unregistered > database ifNotNil: [database logout]. > super unregistered > > I've put the following in #GSRegistrationLogin (my root component for the > app): > > self application preferenceAt: #sessionClass put: GSSession > > And when the user logs out, the following is executed: > > html anchor > callback: [self session expire]; > with: [html paragraph style: 'color: red'; with: [html strong: > 'Logout']] > > But the #unregistered doesn't always get executed. Sometimes, not at all! > And sometimes, much later, as in the *next* time I login and logout (?!). > What am I doing wrong?!! Shouldn't session expiry *always* cause > #unregistered to execute? > > Thanks, > Richard > > ---------------- > John wrote: > > I usually store my glorp session on the seaside session, and upon > expiring, it sends logout to the glorp session. > > This has the dual benefit of the above, and having easy accessor to > glorp in the form of: > > self session glorpSession > > anywhere in my Tasks/Components. > > John _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: Fatal Flaw in my Web App!
|
|
In reply to this post by Sebastian Sastre-2
... which of course won't make it run any sooner. The registry is
configured to expire handlers according to #shouldCollectHandlers and if user closes their browser without clicking your logout button which immediately sends #expire to the session, it will still be subject to the same cleanup conditions. -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. > -----Original Message----- > From: [hidden email] [mailto:seaside- > [hidden email]] On Behalf Of Sebastian Sastre > Sent: Friday, May 23, 2008 12:40 PM > To: 'Seaside - general discussion' > Subject: RE: [Seaside] Fatal Flaw in my Web App! > > Hi Richard, > > I'm overriding #expire in a custom session class to free > (like > persistence sessions). > > cheers, > > Sebastian Sastre > > > > > > > -----Mensaje original----- > > De: [hidden email] > > [mailto:[hidden email]] En nombre > > de Richard K Eng > > Enviado el: Viernes, 23 de Mayo de 2008 16:31 > > Para: Seaside - general discussion > > Asunto: Re: [Seaside] Fatal Flaw in my Web App! > > > > I have a puzzling problem. I've made some changes to do what > > you suggest. > > I've subclassed WASession: > > > > WASession subclass: #GSSession > > > > ...with instance variable #database. I've created > > #unregistered as follows: > > > > unregistered > > database ifNotNil: [database logout]. > > super unregistered > > > > I've put the following in #GSRegistrationLogin (my root > > component for the > > app): > > > > self application preferenceAt: #sessionClass put: GSSession > > > > And when the user logs out, the following is executed: > > > > html anchor > > callback: [self session expire]; > > with: [html paragraph style: 'color: red'; with: > > [html strong: > > 'Logout']] > > > > But the #unregistered doesn't always get executed. Sometimes, > > not at all! > > And sometimes, much later, as in the *next* time I login and > > logout (?!). > > What am I doing wrong?!! Shouldn't session expiry *always* cause > > #unregistered to execute? > > > > Thanks, > > Richard > > > > ---------------- > > John wrote: > > > > I usually store my glorp session on the seaside session, and upon > > expiring, it sends logout to the glorp session. > > > > This has the dual benefit of the above, and having easy accessor to > > glorp in the form of: > > > > self session glorpSession > > > > anywhere in my Tasks/Components. > > > > John > > > > _______________________________________________ > > seaside mailing list > > [hidden email] > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Richard Eng
>
> I just discovered a fatal flaw in my web app. By chance, I > was looking > at the PostgreSQL database for my app, which uses GLORP. When I did > the following in PSQL: > > SELECT * FROM PG_STAT_ACTIVITY; > > I discovered much to my horror that the DB connections from previous > logins/logouts were still lingering around. I had assumed > that they'd > timeout and go away. When I logout, I do a session expire, and I > thought this takes care of all GLORP issues. Apparently, I was dead > wrong! > > Is there a nice easy way for me to solve this without doing major > surgery to my web app? At the time of logout (or even Seaside > session > timeout), I do not necessarily have access to the GLORP instance > variables. > > Thanks, > Richard You shouldn't be holding open a connection per Seaside session in a web app to begin with. You want a Glorp session per Seaside session, not a Postgres connection per Seaside session. Glorp sessions are not tied to any particular connection, you can swap the connection in and out from a connection pool on a per request basis. When a request comes in, grab a connection from your pool, assign it to the current Glorp session, and return it to the pool at the end of the request. Do not rely on Seaside session expiration to manage your connections for you, it's just a bad idea and opens you up to easy denial of service kinds of attacks. There's a connection pool in the GlorpSeaside package or the Glorp package on SqueakSource for just this situation. Ramon Leon http://onsmalltalk.com _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: Fatal Flaw in my Web App!
|
|
In reply to this post by Boris Popov, DeepCove Labs (SNN)
...and that's why we use connection pools for those sessions right?
Sebastian Sastre > -----Mensaje original----- > De: [hidden email] > [mailto:[hidden email]] En nombre > de Boris Popov > Enviado el: Viernes, 23 de Mayo de 2008 16:48 > Para: Seaside - general discussion > Asunto: RE: [Seaside] Fatal Flaw in my Web App! > > ... which of course won't make it run any sooner. The registry is > configured to expire handlers according to > #shouldCollectHandlers and if > user closes their browser without clicking your logout button which > immediately sends #expire to the session, it will still be subject to > the same cleanup conditions. > > -Boris > > -- > +1.604.689.0322 > DeepCove Labs Ltd. > 4th floor 595 Howe Street > Vancouver, Canada V6C 2T5 > http://tinyurl.com/r7uw4 > > [hidden email] > > CONFIDENTIALITY NOTICE > > This email is intended only for the persons named in the message > header. Unless otherwise indicated, it contains information that is > private and confidential. If you have received it in error, please > notify the sender and delete the entire message including any > attachments. > > Thank you. > > > -----Original Message----- > > From: [hidden email] [mailto:seaside- > > [hidden email]] On Behalf Of Sebastian Sastre > > Sent: Friday, May 23, 2008 12:40 PM > > To: 'Seaside - general discussion' > > Subject: RE: [Seaside] Fatal Flaw in my Web App! > > > > Hi Richard, > > > > I'm overriding #expire in a custom session class to free > resources > > (like > > persistence sessions). > > > > cheers, > > > > Sebastian Sastre > > > > > > > > > > > > > -----Mensaje original----- > > > De: [hidden email] > > > [mailto:[hidden email]] En nombre > > > de Richard K Eng > > > Enviado el: Viernes, 23 de Mayo de 2008 16:31 > > > Para: Seaside - general discussion > > > Asunto: Re: [Seaside] Fatal Flaw in my Web App! > > > > > > I have a puzzling problem. I've made some changes to do what > > > you suggest. > > > I've subclassed WASession: > > > > > > WASession subclass: #GSSession > > > > > > ...with instance variable #database. I've created > > > #unregistered as follows: > > > > > > unregistered > > > database ifNotNil: [database logout]. > > > super unregistered > > > > > > I've put the following in #GSRegistrationLogin (my root > > > component for the > > > app): > > > > > > self application preferenceAt: #sessionClass put: GSSession > > > > > > And when the user logs out, the following is executed: > > > > > > html anchor > > > callback: [self session expire]; > > > with: [html paragraph style: 'color: red'; with: > > > [html strong: > > > 'Logout']] > > > > > > But the #unregistered doesn't always get executed. Sometimes, > > > not at all! > > > And sometimes, much later, as in the *next* time I login and > > > logout (?!). > > > What am I doing wrong?!! Shouldn't session expiry *always* cause > > > #unregistered to execute? > > > > > > Thanks, > > > Richard > > > > > > ---------------- > > > John wrote: > > > > > > I usually store my glorp session on the seaside session, and upon > > > expiring, it sends logout to the glorp session. > > > > > > This has the dual benefit of the above, and having easy > accessor to > > > glorp in the form of: > > > > > > self session glorpSession > > > > > > anywhere in my Tasks/Components. > > > > > > John > > > > > > _______________________________________________ > > > seaside mailing list > > > [hidden email] > > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > > _______________________________________________ > > seaside mailing list > > [hidden email] > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
On Fri, 2008-05-23 at 17:32 -0300, Sebastian Sastre wrote:
> ...and that's why we use connection pools for those sessions right? > The main objective to use the pools is to save connections. As databases are getting slower with increasing number of connections you should think about keeping them low. As Ramon said, database sessions aren't tied to connections so a pool is good to achieve it. I have 10 images running with each of them having approx. 2 connections open. Btw. the connection pool is also a protection against stalled connections. Norbert > Sebastian Sastre > > > > > -----Mensaje original----- > > De: [hidden email] > > [mailto:[hidden email]] En nombre > > de Boris Popov > > Enviado el: Viernes, 23 de Mayo de 2008 16:48 > > Para: Seaside - general discussion > > Asunto: RE: [Seaside] Fatal Flaw in my Web App! > > > > ... which of course won't make it run any sooner. The registry is > > configured to expire handlers according to > > #shouldCollectHandlers and if > > user closes their browser without clicking your logout button which > > immediately sends #expire to the session, it will still be subject to > > the same cleanup conditions. > > > > -Boris > > > > -- > > +1.604.689.0322 > > DeepCove Labs Ltd. > > 4th floor 595 Howe Street > > Vancouver, Canada V6C 2T5 > > http://tinyurl.com/r7uw4 > > > > [hidden email] > > > > CONFIDENTIALITY NOTICE > > > > This email is intended only for the persons named in the message > > header. Unless otherwise indicated, it contains information that is > > private and confidential. If you have received it in error, please > > notify the sender and delete the entire message including any > > attachments. > > > > Thank you. > > > > > -----Original Message----- > > > From: [hidden email] [mailto:seaside- > > > [hidden email]] On Behalf Of Sebastian Sastre > > > Sent: Friday, May 23, 2008 12:40 PM > > > To: 'Seaside - general discussion' > > > Subject: RE: [Seaside] Fatal Flaw in my Web App! > > > > > > Hi Richard, > > > > > > I'm overriding #expire in a custom session class to free > > resources > > > (like > > > persistence sessions). > > > > > > cheers, > > > > > > Sebastian Sastre > > > > > > > > > > > > > > > > > > > -----Mensaje original----- > > > > De: [hidden email] > > > > [mailto:[hidden email]] En nombre > > > > de Richard K Eng > > > > Enviado el: Viernes, 23 de Mayo de 2008 16:31 > > > > Para: Seaside - general discussion > > > > Asunto: Re: [Seaside] Fatal Flaw in my Web App! > > > > > > > > I have a puzzling problem. I've made some changes to do what > > > > you suggest. > > > > I've subclassed WASession: > > > > > > > > WASession subclass: #GSSession > > > > > > > > ...with instance variable #database. I've created > > > > #unregistered as follows: > > > > > > > > unregistered > > > > database ifNotNil: [database logout]. > > > > super unregistered > > > > > > > > I've put the following in #GSRegistrationLogin (my root > > > > component for the > > > > app): > > > > > > > > self application preferenceAt: #sessionClass put: GSSession > > > > > > > > And when the user logs out, the following is executed: > > > > > > > > html anchor > > > > callback: [self session expire]; > > > > with: [html paragraph style: 'color: red'; with: > > > > [html strong: > > > > 'Logout']] > > > > > > > > But the #unregistered doesn't always get executed. Sometimes, > > > > not at all! > > > > And sometimes, much later, as in the *next* time I login and > > > > logout (?!). > > > > What am I doing wrong?!! Shouldn't session expiry *always* cause > > > > #unregistered to execute? > > > > > > > > Thanks, > > > > Richard > > > > > > > > ---------------- > > > > John wrote: > > > > > > > > I usually store my glorp session on the seaside session, and upon > > > > expiring, it sends logout to the glorp session. > > > > > > > > This has the dual benefit of the above, and having easy > > accessor to > > > > glorp in the form of: > > > > > > > > self session glorpSession > > > > > > > > anywhere in my Tasks/Components. > > > > > > > > John > > > > > > > > _______________________________________________ > > > > seaside mailing list > > > > [hidden email] > > > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > > > > _______________________________________________ > > > seaside mailing list > > > [hidden email] > > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > _______________________________________________ > > seaside mailing list > > [hidden email] > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |