Login form via ssl (https)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Login form via ssl (https)

Dave
Hi there,
 I'm implementing a login form and I need ssl to secure it.
Unfortunately I can't find on the list or on the internet a straight way to solve my issue.
Seaside behind nginx, so nginx manages ssl so far so good.
With the help of this hint: http://forum.world.st/from-http-to-https-tc997547.html#a997580 I saw how to generate a secure link, but my question is: I have a form with login and password fields, how should I change the code to generate a https url?

I'm hacking a bit, but I don't know how to manage call: and answer: and switching between http and https
The following code is what I tried:


MyComponent>>renderContentOn: html
 html anchor secureCallback: [self call: MyLogin new]; with: [html span:'Login'].



MyLogin>>renderContentOn: html
html form
                with: [html textInput on: #username of: self session; placeholder: 'username'.
                                html textInput on: #password of: self session; placeholder: 'password'.
                                html submitButton callback: [ self session validateLogin.
                                                                                                self answer]; value: 'login'].



for the definition of secureCallback: see http://forum.world.st/from-http-to-https-tc997547.html#a997580

Clicking the submit button does not switch back to http, of course, but I don't know how to solve it. Any hint?
Thanks
 Dav
Reply | Threaded
Open this post in threaded view
|

RE: Login form via ssl (https)

Boris Popov, DeepCove Labs (SNN)
Any specific reason you don't just want your whole application to be SSL-secured?

-Boris


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Dav
Sent: Sunday, September 23, 2012 11:15 AM
To: [hidden email]
Subject: [Seaside] Login form via ssl (https)

Hi there,
 I'm implementing a login form and I need ssl to secure it.
Unfortunately I can't find on the list or on the internet a straight way to solve my issue.
Seaside behind nginx, so nginx manages ssl so far so good.
With the help of this hint:
http://forum.world.st/from-http-to-https-tc997547.html#a997580 I saw how to generate a secure link, but my question is: I have a form with login and password fields, how should I change the code to generate a https url?

I'm hacking a bit, but I don't know how to manage call: and answer: and switching between http and https The following code is what I tried:


MyComponent>>renderContentOn: html
 html anchor secureCallback: [self call: MyLogin new]; with: [html span:'Login'].



MyLogin>>renderContentOn: html
html form
                with: [html textInput on: #username of: self session; placeholder:
'username'.
                                html textInput on: #password of: self session; placeholder: 'password'.
                                html submitButton callback: [ self session validateLogin.
                                                                                                self answer]; value: 'login'].



for the definition of secureCallback: see
http://forum.world.st/from-http-to-https-tc997547.html#a997580

Clicking the submit button does not switch back to http, of course, but I don't know how to solve it. Any hint?
Thanks
 Dav



--
View this message in context: http://forum.world.st/Login-form-via-ssl-https-tp4648556.html
Sent from the Seaside General mailing list archive at Nabble.com.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

RE: Login form via ssl (https)

Dave
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
Reply | Threaded
Open this post in threaded view
|

RE: Login form via ssl (https)

Paul DeBruicker
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
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

RE: Login form via ssl (https)

Dave
Hi Paul,
 I like your solution, your use of url rewriting and extraPath is really good.
Thanks for the help!
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
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

RE: Login form via ssl (https)

Dave
In reply to this post by Paul DeBruicker
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:

location @mySeasideApp {
            proxy_pass http://127.0.0.1:8080;
       }

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
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

RE: Login form via ssl (https)

Paul DeBruicker
I'm away from my computer but I think outside of the server definitions I have something to the effect of:

upstream seaside {
       127.0.0.1:8080
}

And inside the mySiteDetails.conf there's a location:

location @mySeasideApp {
proxy_pass http://seaside
}


On Sep 23, 2012, at 11:28 AM, Dav <[hidden email]> 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
>>> Sent from the Seaside General mailing list archive at Nabble.com.
>>> _______________________________________________
>>> seaside mailing list
>>>
>
>> seaside@.squeakfoundation
>
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>
>>
>> _______________________________________________
>> seaside mailing list
>
>> seaside@.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.
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

RE: Login form via ssl (https)

Dave
Hi Paul,
 I see, but I don't think it solves the extrapath issue.
Dave

Paul DeBruicker wrote
I'm away from my computer but I think outside of the server definitions I have something to the effect of:

upstream seaside {
       127.0.0.1:8080
}

And inside the mySiteDetails.conf there's a location:

location @mySeasideApp {
proxy_pass http://seaside
}


On Sep 23, 2012, at 11:28 AM, Dav <[hidden email]> 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
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

RE: Login form via ssl (https)

Paul DeBruicker
On 09/24/2012 02:19 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


I'm missing the bit where you describe how you wrote your @mySeasideApp
section.

You probably need to set up something in the #initialRequest: method on
the instance side of your main class to look for an react to the /signin
part


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

RE: Login form via ssl (https)

Dave
Hi Paul,
 Look at: http://forum.world.st/Login-form-via-ssl-https-tp4648556p4648581.html
for @mySeasideApp

Dave

Paul DeBruicker wrote

I'm missing the bit where you describe how you wrote your @mySeasideApp
section.

You probably need to set up something in the #initialRequest: method on
the instance side of your main class to look for an react to the /signin
part


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

RE: Login form via ssl (https)

Paul DeBruicker
In reply to this post by Dave
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]
> <mailto:[hidden email]>> 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@.squeakfoundation
>
>
>                 http://lists.squeakfoundation.__org/cgi-bin/mailman/listinfo/__seaside
>                 <http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside>
>
>
>             _________________________________________________
>             seaside mailing list
>
>
>             seaside@.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]
>         <mailto:[hidden email]>
>         http://lists.squeakfoundation.__org/cgi-bin/mailman/listinfo/__seaside
>         <http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside>
>
>
>

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Login form via ssl (https)

Dave
Probably you are right, the ^~ is important.
Thx
 Dave

On Tue, Sep 25, 2012 at 5:44 PM, Paul DeBruicker [via Smalltalk] <[hidden email]> 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]
> <mailto:[hidden email]>> 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="<a href="https://encrypted.google.com/__search?hl=en&amp;q=nginx%20remove%__20part%20of%20path%20from%__20url" target="_blank">https://encrypted.google.com/__search?hl=en&q=nginx%20remove%__20part%20of%20path%20from%__20url"><a href="https://encrypted.google.com/__search?hl=en&amp;q=nginx%20remove%__20part%20of%20path%20from%__20url" target="_blank">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@.squeakfoundation
>
>
>                 http://lists.squeakfoundation.__org/cgi-bin/mailman/listinfo/__seaside
>                 <http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside>

>
>
>             _________________________________________________
>             seaside mailing list
>
>
>             seaside@.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]
>         <mailto:[hidden email]>
>         http://lists.squeakfoundation.__org/cgi-bin/mailman/listinfo/__seaside
>         <http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside>
>
>
>

_______________________________________________
seaside mailing list
[hidden email]
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.
NAML

Reply | Threaded
Open this post in threaded view
|

RE: Login form via ssl (https)

Dave
In reply to this post by Paul DeBruicker
Hi,
 Eventually I chose Boris' solution, I migrated all urls to https and I redirected http to https as Paul explained.
Thank you all
Dave