<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 3, 2015 at 10:10 AM, Johan Brichau <span dir="ltr"><<a href="mailto:johan@inceptive.be" target="_blank">johan@inceptive.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>They only way I can think of is to store a session id in the browser sessionStorage, which is unique to each tab.</div><div>However, I do not think anyone has done so yet.</div></div></blockquote><div><br></div><div>Thanks for the idea, I wasn't aware of the sessionStorage. I will read about it. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div>The question that pops to my mind is: why do you want to hide the _s in the url? If this is about security, it’s probably because you do not want someone to copy/paste the url and hijack the session?</div></blockquote><div><br></div><div>Exactly. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>You can prevent that by not using the session to track authentication, but a cookie. In other words:</div><div>- use a cookie for authentication (i.e. always require the cookie to be present)</div><div>- keep _s for session tracking</div><div>-> a user will need both the session id in the url _and_ the cookie to work<br><div><div><div><br></div></div></div></div></div></blockquote><div><br></div><div>That's exactly what I ended up doing. But I wanted to be able to have multiple sessions so the same cookie keeps a list of active sessions. Also, the session ID stored in the cookie are not the plain session ID because otherwise it would be very simple to hack. So when a new session ID is created I create another random token and I store that in a table at server side. And yes, I keep using _s for tracking. For this, I made a subclass of WAHandlerTrackingStrategy.</div><div><br></div><div>Then I had to make a request filter that would get the session ID from the _s and check if there is a cookie that holds a correct "token" for that cookie. </div><div><br></div><div>If someone else is interested in this code I can share it. Even more if a "seaside dev" guy could take a brief look since I suspect I may be missing scenarios (like document handler expiration vs session expiration). </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div><div></div><div>But perhaps there is another reason to keep the _s out of the url?</div><div><br></div><div>cheers</div><div>Johan</div><div><br><div><blockquote type="cite"><div><div class="h5"><div>On 01 Oct 2015, at 15:20, Mariano Martinez Peck <<a href="mailto:marianopeck@gmail.com" target="_blank">marianopeck@gmail.com</a>> wrote:</div><br></div></div><div><div><div class="h5"><div dir="ltr">Hi guys, <div><br></div><div>I am evaluating some improvements for an app, and I would like these 2 features:</div><div><br></div><div>1) Do not expose _s in URL </div><div>2) I want to be able to open multiple different seaside sessions from different tabs of the browser. </div><div><br></div><div>I was checking the WACookieSessionTrackingStrategy subclasses but of course that is not gonna work because if I have multiple sessions opened in the browser, at #cookieFromContext:ifAbsent: there is no way I can guess which is the real session I must answer for that request. </div><div>I am not against using cookies, but I cannot see how that could work. Anyone has a workaround?</div><div><br></div><div>As a second thought, I saw WASslSessionTrackingStrategy (my site does run with HTTPS over nginx) which looked interesting. Has someone used this before? I have read a couple of problems with it:<br clear="all"><div><br></div><div><div><i>"<span style="white-space:pre-wrap"> </span>An interval that is too short can cause a premature termination of a session.</i></div><div><i>Also, some Web browsers might have their own timers that affect the lifetime of the SSL session ID. These Web browsers may not leave the SSL session ID active long enough to serve as a useful mechanism for session tracking.</i></div><div><i>"</i></div></div><div><br></div><div>I seems the timeout can be easily set in nginx. But I am wondering about what it says about browsers killing inactive SSL sessions IDs. Have anyone experienced this?</div><div><br></div><div>Thanks in advance, </div><div><br></div>-- <br><div>Mariano<br><a href="http://marianopeck.wordpress.com/" target="_blank">http://marianopeck.wordpress.com</a><br></div>
</div></div></div></div>
_______________________________________________<br>seaside mailing list<br><a href="mailto:seaside@lists.squeakfoundation.org" target="_blank">seaside@lists.squeakfoundation.org</a><br><a href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside" target="_blank">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a><br></div></blockquote></div><br></div></div></div></div></div><br>_______________________________________________<br>
seaside mailing list<br>
<a href="mailto:seaside@lists.squeakfoundation.org">seaside@lists.squeakfoundation.org</a><br>
<a href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside" rel="noreferrer" target="_blank">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Mariano<br><a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br></div>
</div></div>