[Seaside] RE: Login form via ssl (https)

[Dav]

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
>> 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
>>
> 
> _______________________________________________
> seaside mailing list

> seaside at .squeakfoundation

> 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
Sent from the Seaside General mailing list archive at Nabble.com.