Re: Ajax refresh component with initial setVisible(false)
Please help me out hereis there any silly mistake that I am making? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Ajax-refresh-component-with-initial-setVisible-false-tp4650171p4650205.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Determine session size for Wicket 1.5
On Fri, Jun 22, 2012 at 11:28 PM, Walter Rugora wrote:
> Hi,
>
> when I apply the Wicket 1.3 way to determine session size,
> RequestCycle.get().getSession().getSizeInBytes()
> it results in an around 3000bytes value in my case. And adding or
> removing Labels changed the session size.
>
> Now with Wicket 1.5 using
> Session.get().getSizeInBytes()
> session size is 857bytes. And I can add or remove as many Lables as I
> wish, that size stays the same. Obviously I use it wrong. Currently I
> just add the session size result to a Label added to my single WebPage:
> public HomePage(final PageParameters parameters) {
> ...
> add(new Label("ssize", String.valueOf(Session.get().getSizeInBytes(;
> ...
> }
>
Here you're doing it in the constructor. So, if this is the first page you
visit there won't be any (Wicket) stuff in the session yet.
Have you tried just adding the debug bar to your page? Add a dependency to
wicket-devutils in your pom.xml and then add(new DebugBar("someID")); to
your page (and add it to the markup obviously).
--
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: AjaxLink.onClick() Not Triggered
try to change jquery version, i have the same probleme with jquery 1.4.2 , AjaxLink not triggred but when i change jquery to 1.7.2 it works -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/AjaxLink-onClick-Not-Triggered-tp4400731p4650202.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Appending onbeforeunload javascript function and then disabling it
Dear Forum, I have this panel in which I make an ajax button visible via ajax. Also, I append the following javascript to the AjaxRequestTarget to prevent the user from navigating away: When the user clicks on the ajax button, I hide it and I no longer prevent him/her from navigating away so I append the following javascript to the AjaxRequestTarget: and this works (I got this answer from http://stackoverflow.com/a/9717750/158499 stackoverflow ). My question is, in wicket, is there any negative consequences to constantly appending the mentioned javascript/jquery code to the AjaxRequestTarget? I just don't know any other way to disabling such behaviour and I applied the one solution I know. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Appending-onbeforeunload-javascript-function-and-then-disabling-it-tp4650203.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: logout
Which means that upon logout, these values should be removed / cleared. A session does not represent a user, it is a construct to bind request, no more no less. All other usages are bolted on and should be bolted off. You don't tear down the house, just because you are moving. Tom On 2012-06-23 10:18, Bert wrote: But Wicket also stores the page map in the session to support back button functionality. If you only change the status, than the user could possibly (depending on how you construct your page) go back after the logout and see the last pages. This could be a problem on public computers. You could also see a session as representing a user, not a browser. Than, invalidating the session on logout makes perfect sense to me. regards - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: logout
But Wicket also stores the page map in the session to support back button functionality. If you only change the status, than the user could possibly (depending on how you construct your page) go back after the logout and see the last pages. This could be a problem on public computers. You could also see a session as representing a user, not a browser. Than, invalidating the session on logout makes perfect sense to me. regards On Sat, Jun 23, 2012 at 9:14 AM, Tom Eugelink wrote: > On 2012-06-22 16:57, Tom Eugelink wrote: >> >> Anyhow, I've added Wicket Auth/Roles >> (http://wicket.apache.org/learn/projects/authroles.html) as the security >> framework and it is working fine except one thing; logging out. > > > I've found that the login / logout logic is invalidating the session. During > an attempt to setup security in a webapp years back, I found that Tomcat > also does this and I never understood why. The session is a technical > construct that binds requests from the same browser and allows the website > to become coherent over multiple request. It has nothing to do with an > authentication state. Naturally it can be used as a means to administer if a > user is logged in, but there is no reason to trash the session when a user > is logging out; after all, it's still the same brower sending requests. The > session has not changed, the user's status has. > > The security filter I've implemented years back as a result of this > discovery simply changes the logged in state in the current session. If any > attributes need to be cleared when a user logs out, this is easily done by > removing them from the current session (may even by using a special map > store as an attribute in the session). This will prevent the automatic login > I'm experiencing now. I will roll my security filter in to my wicket app. > > > Tom > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: logout
On 2012-06-22 16:57, Tom Eugelink wrote: Anyhow, I've added Wicket Auth/Roles (http://wicket.apache.org/learn/projects/authroles.html) as the security framework and it is working fine except one thing; logging out. I've found that the login / logout logic is invalidating the session. During an attempt to setup security in a webapp years back, I found that Tomcat also does this and I never understood why. The session is a technical construct that binds requests from the same browser and allows the website to become coherent over multiple request. It has nothing to do with an authentication state. Naturally it can be used as a means to administer if a user is logged in, but there is no reason to trash the session when a user is logging out; after all, it's still the same brower sending requests. The session has not changed, the user's status has. The security filter I've implemented years back as a result of this discovery simply changes the logged in state in the current session. If any attributes need to be cleared when a user logs out, this is easily done by removing them from the current session (may even by using a special map store as an attribute in the session). This will prevent the automatic login I'm experiencing now. I will roll my security filter in to my wicket app. Tom - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
