[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