[Seaside] RE: Login form via ssl (https)
Paul DeBruicker
pdebruic at gmail.com
Tue Sep 25 15:44:37 UTC 2012
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 <pdebruic at gmail.com
> <mailto:pdebruic at gmail.com>> 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?
> 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
> seaside at lists.__squeakfoundation.org
> <mailto:seaside at lists.squeakfoundation.org>
> http://lists.squeakfoundation.__org/cgi-bin/mailman/listinfo/__seaside
> <http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside>
>
>
>
More information about the seaside
mailing list