[Seaside] Re: Login form via ssl (https)
Dav
lasmiste at gmail.com
Wed Sep 26 13:49:19 UTC 2012
Probably you are right, the ^~ is important.
Thx
Dave
On Tue, Sep 25, 2012 at 5:44 PM, Paul DeBruicker [via Smalltalk] <
ml-node+s1294792n4648953h24 at n4.nabble.com> wrote:
> Ahh. Ok. Yeah your @mySeasideApp section looks fine.
>
>
> The way I wrote this part of the https server config:
>
> location ^~ /signin {
> try_files $uri @mySeasideApp
> }
>
> tells nginx to stop checking other rules and process that one (the ^~
> part stops searching on match:
> http://wiki.nginx.org/HttpCoreModule#location). So it would depend on
> how you added the rewrite to your configuration for the https server.
> Nginx may never get to it.
>
>
>
>
>
>
>
> On 09/25/2012 01:07 AM, Lasmiste wrote:
>
> > Hi Paul,
> > I did a search on google and tried the first result
> >
> http://superuser.com/questions/435916/nginx-rewrite-rule-to-remove-path-node
> > (it seemed to me trivial), well, it works on my http section in ngninx,
> > but it does not work in https section, that's really weird, probably
> > it's something I'm missing.
> > Cheers
> > Dave
> >
> >
> > On Mon, Sep 24, 2012 at 8:11 PM, Paul DeBruicker <[hidden email]<http://user/SendEmail.jtp?type=node&node=4648953&i=0>
> > <mailto:[hidden email]<http://user/SendEmail.jtp?type=node&node=4648953&i=1>>>
> wrote:
> >
> > In my email clients (iOS mail app and Thunderbird) the place where
> > you specify your @mySeasideApp below shows nothing.
> >
> >
> > Do you think you're still having a problem with that part or is it
> > just url rewriting with nginx now?
> > <a href="
> https://encrypted.google.com/__search?hl=en&q=nginx%20remove%__20part%20of%20path%20from%__20url
> ">
> https://encrypted.google.com/__search?hl=en&q=nginx%20remove%__20part%20of%20path%20from%__20url
>
> > <
> https://encrypted.google.com/search?hl=en&q=nginx%20remove%20part%20of%20path%20from%20url>
>
> >
> >
> >
> >
> >
> >
> >
> > On 09/23/2012 11:28 AM, Dav wrote:
> >
> > Hi Paul,
> > I can't make it work, probably due to my lack of knowledge of
> > nginx
> >
> > Let's take the signin example. I wrote @mySeasideApp like this:
> >
> >
> >
> > That's because my seaside app is running on 8080, but
> > unfortunately when I
> > click on the signin anchor, my browser reply: "/signin not
> found"
> > I think that nginx should remove the /signin extrapath when it
> > redirects to
> > 8080, but I don't know how.
> > Can you help me?
> > Thanks
> > Dave
> >
> >
> >
> >
> > Paul DeBruicker wrote
> >
> > I think you can change it with two server definitions in
> > nginx and never
> > mess with Seaside's https/http functionality at all, ever.
> >
> >
> > e.g. If the link is to http://example.com/signin
> > http://example.com/signup or http://example.com/backend and
> > the client
> > attempts to connect via http I rewrite & redirect to https
> > with nginx
> > and pass the request to Seaside. The SSL connections are
> > terminated at
> > Nginx. All my links in my Seaside app are just regular
> > anchors/buttons
> > with plain callbacks. The public site can be accessed via
> > http or
> > https. The sign-in, sign-up and backend portions are always
> > SSL.
> >
> > The signin form link becomes
> >
> > html anchor
> > useBaseUrl;
> > extraPath:'signin';
> > callback:[self showSignin];
> > with:'Sign In'.
> >
> >
> > Once the user authenticates it would seem to make sense to
> > serve them
> > only via SSL for the duration of their session to increase
> the
> > probability that none of their info leaks. Plus the cost in
> > engineering
> > time to forever maintain a mental model of which links
> > should be secure
> > or not seems high relative to the cost of just the cpu time
> > to just make
> > everything SSL.
> >
> >
> >
> >
> > The Nginx server directives I use are:
> > server {
> >
> > listen 80;
> > include sites-available/mySiteDetails.__conf;
> >
> > location ^~ /backend {
> > rewrite ^/(.*)$
> > https://www.example.com/$1 redirect;
> > }
> >
> > location ^~ /signin {
> > rewrite ^/(.*)$
> > https://www.example.com/$1 redirect;
> > }
> > location ^~ /signup {
> > rewrite ^/(.*)$
> > https://www.example.com/$1 redirect;
> > }
> > }
> >
> > server {
> > listen 443 ssl;
> > ssl_certificate
> /usr/local/nginx/conf/myApp.__cert;
> > ssl_certificate_key
> /usr/local/nginx/conf/myApp.__key;
> > include sites-available/mySiteDetails.__conf;
> > location ^~ /backend {
> > try_files $uri @mySeasideApp;
> > }
> > location ^~ /signin {
> > try_files $uri @mySeasideApp;
> > }
> > location ^~ /signup {
> > try_files $uri @mySeasideApp;
> > }
> > }
> >
> >
> > Hope this helps
> >
> > Paul
> >
> >
> >
> >
> >
> > On 09/23/2012 09:11 AM, Dav wrote:
> >
> > Hi Boris,
> > Actually I have secured and not secured links, and
> > it's a lot of work
> > change it, so I prefer only to secure login. Is it
> > really so difficult in
> > seaside?
> > Cheers
> > Dave
> >
> >
> > Boris Popov, DeepCove Labs (SNN) wrote
> >
> > Any specific reason you don't just want your whole
> > application to be
> > SSL-secured?
> >
> > -Boris
> >
> >
> >
> >
> >
> >
> > --
> > View this message in context:
> >
> http://forum.world.st/Login-__form-via-ssl-https-__tp4648556p4648566.html
>
> > <
> http://forum.world.st/Login-form-via-ssl-https-tp4648556p4648566.html>
> > Sent from the Seaside General mailing list archive at
> > Nabble.com.
> > _________________________________________________
> > seaside mailing list
> >
> >
> > seaside at .squeakfoundation
> >
> >
> >
> http://lists.squeakfoundation.__org/cgi-bin/mailman/listinfo/__seaside
> > <
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside>
> >
> >
> > _________________________________________________
> > seaside mailing list
> >
> >
> > seaside at .squeakfoundation
> >
> >
> >
> http://lists.squeakfoundation.__org/cgi-bin/mailman/listinfo/__seaside
> > <
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside>
> >
> >
> >
> >
> >
> >
> > --
> > View this message in context:
> >
> http://forum.world.st/Login-__form-via-ssl-https-__tp4648556p4648581.html
> > <
> http://forum.world.st/Login-form-via-ssl-https-tp4648556p4648581.html>
> >
> > Sent from the Seaside General mailing list archive at
> Nabble.com.
> > _________________________________________________
> > seaside mailing list
> > [hidden email]<http://user/SendEmail.jtp?type=node&node=4648953&i=2>
> > <mailto:[hidden email]<http://user/SendEmail.jtp?type=node&node=4648953&i=3>>
>
> >
> http://lists.squeakfoundation.__org/cgi-bin/mailman/listinfo/__seaside
> > <
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside>
> >
> >
> >
>
> _______________________________________________
> seaside mailing list
> [hidden email] <http://user/SendEmail.jtp?type=node&node=4648953&i=4>
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
> http://forum.world.st/Login-form-via-ssl-https-tp4648556p4648953.html
> To unsubscribe from Login form via ssl (https), click here<http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4648556&code=bGFzbWlzdGVAZ21haWwuY29tfDQ2NDg1NTZ8ODU4NTA0NTc3>
> .
> NAML<http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
View this message in context: http://forum.world.st/Login-form-via-ssl-https-tp4648556p4649097.html
Sent from the Seaside General mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20120926/6464a8aa/attachment-0001.htm
More information about the seaside
mailing list