Login form via ssl (https)
Locked
 
|
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 |
RE: Login form via ssl (https)
|
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 |
|
|
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
|
RE: Login form via ssl (https)
|
|
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 |
|
|
Hi Paul,
I like your solution, your use of url rewriting and extraPath is really good. Thanks for the help! 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
|
RE: Login form via ssl (https)
|
|
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 |
|
|
Hi Paul,
I see, but I don't think it solves the extrapath issue. Dave
|
RE: Login form via ssl (https)
|
|
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 |
|
|
Hi Paul,
Look at: http://forum.world.st/Login-form-via-ssl-https-tp4648556p4648581.html for @mySeasideApp Dave
|
RE: Login form via ssl (https)
|
|
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 |
|
|
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:
|
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |