Making a store in Seaside
Locked
 
|
Hello all,
I am creating a store website somewhat like the example sushi store. I'm sure other people must have sites like this, so my question is; what is the current best practice for doing the credit card part of the transaction? On traditional sites, you surf with normal http and when you get to the part of inputting the credit card you are redirected to the https part of the site to complete the transaction. Is there any way to do this in Seaside? The issue is, the user spends the entire time of their visit inputing the information about what they want to buy so this has to get passed to the https site somehow. So here are the ways I thought of that this can be solved in order of most desirable to least desirable. 1. Native handling. I can just say something like: self call: SecuredComponent withCart: myCart. and the new object will be displayed, it just happens that it's displayed over https (this includes a transparent redirect as part of the component). 2. Native handling, but different web server. I start up a second Smalltalk web server that is https only and create an application that has a REST type interface and only does credit card transactions. Then at the point where I switch to credit card mode, I actually redirect the user to the https web server. This will require the https application to override the 2 url reading methods to allow the REST type interface. The http application would need to call the https like: https://myOtherApp/masterCard/11111. This would mean to do the master card handling and retrieve the cart from magma or some other store in the image where the id is 11111. 3. Native server, but 100% https. Just write the application as the sushi store is and run the web server https only. This requires the opening page to simply redirect to the https site immediately. I don't like this solution because it will slow down the entire site. The nature of shopping is that you have many more people looking then buying. Having the whole site under 100% https means I can serve less clients at a time and the majority pays the price for the few. 4. Native server but tunneled through some 3rd party tunneler (perhaps apache). This would be more speed/clients then approach 3 but is more complicated to set up and still has the problems of 3, they just don't show up as quickly. 5. Give up. Prototype the site in seaside, then when all looks good port it to Erlang Yaws so that I can at least maintain a homogeneous solution that is almost as easy to configure as a Seaside solution. It will take longer to write the solution in Yaws then it would in Seaside, but it will come with benefits (e.g. scaling is no longer a concern, comes with a very nice distributed database, etc.). 6. Big ball of mud. Set up a big complicated apache solution with all kinds of URL rewriting and other such things so that the part where the credit card is entered is automatically put through some tunneling solution. So, how many of these are available today, and how many of them could be implemented (by me if someone else isn't already doing it) in the near term? Thanks, Jason _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
> 1. Native handling. I can just say something like: self call:
> SecuredComponent withCart: myCart. and the new object will be > displayed, it just happens that it's displayed over https (this includes > a transparent redirect as part of the component). I would go with this approach. You create a decoration and in #updateRoot: you change the URL from http to https. Whenever you need security you add this decoration, whenever you don't you remove it. This assumes that you have an identical Apache setup for http and https, but that shouldn't be a problem. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Making a store in Seaside
|
|
In reply to this post by Jason Johnson-3
Don't you have to set server protocol as a setting on an application? _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
> Don't you have to set server protocol as a setting on an application?
I admit that I've never tried this, but it should actually work to change the protocol on the fly using #updateUrl:. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: Making a store in Seaside
|
|
In reply to this post by Jason Johnson-3
I'm also was thinking about an 1 (secured component) approach to collect
data to pass to the outsourced payment service. Sebastian > -----Mensaje original----- > De: [hidden email] > [mailto:[hidden email]] En nombre > de Jason Johnson > Enviado el: Miércoles, 12 de Septiembre de 2007 02:48 > Para: The Squeak Enterprise Aubergines Server - general discussion. > Asunto: [Seaside] Making a store in Seaside > > Hello all, > > I am creating a store website somewhat like the example sushi store. > I'm sure other people must have sites like this, so my > question is; what is the current best practice for doing the > credit card part of the transaction? > > On traditional sites, you surf with normal http and when you > get to the part of inputting the credit card you are > redirected to the https part of the site to complete the > transaction. Is there any way to do this in Seaside? The > issue is, the user spends the entire time of their visit > inputing the information about what they want to buy so this > has to get passed to the https site somehow. So here are the > ways I thought of that this can be solved in order of most > desirable to least desirable. > > 1. Native handling. I can just say something like: self call: > SecuredComponent withCart: myCart. and the new object will be > displayed, it just happens that it's displayed over https > (this includes a transparent redirect as part of the component). > > 2. Native handling, but different web server. I start up a > second Smalltalk web server that is https only and create an > application that has a REST type interface and only does > credit card transactions. Then at the point where I switch > to credit card mode, I actually redirect the user to the > https web server. This will require the https application to > override the 2 url reading methods to allow the REST type interface. > The http application would need to call the https like: > https://myOtherApp/masterCard/11111. This would mean to do > the master card handling and retrieve the cart from magma or > some other store in the image where the id is 11111. > > 3. Native server, but 100% https. Just write the > application as the sushi store is and run the web server > https only. This requires the opening page to simply > redirect to the https site immediately. I don't like this > solution because it will slow down the entire site. The > nature of shopping is that you have many more people looking > then buying. Having the whole site under 100% https means I > can serve less clients at a time and the majority pays the > price for the few. > > 4. Native server but tunneled through some 3rd party > tunneler (perhaps apache). This would be more speed/clients > then approach 3 but is more complicated to set up and still > has the problems of 3, they just don't show up as quickly. > > 5. Give up. Prototype the site in seaside, then when all > looks good port it to Erlang Yaws so that I can at least > maintain a homogeneous solution that is almost as easy to > configure as a Seaside solution. It will take longer to > write the solution in Yaws then it would in Seaside, but it > will come with benefits (e.g. scaling is no longer a concern, > comes with a very nice distributed database, etc.). > > 6. Big ball of mud. Set up a big complicated apache > solution with all kinds of URL rewriting and other such > things so that the part where the credit card is entered is > automatically put through some tunneling solution. > > So, how many of these are available today, and how many of > them could be implemented (by me if someone else isn't > already doing it) in the near term? > > Thanks, > Jason > _______________________________________________ > 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 |
Re: Making a store in Seaside
|
|
Is anyone else doing things like this? I know Keith had mentioned he
was working on a store. There must be others as well, no? Sebastian Sastre wrote: > I'm also was thinking about an 1 (secured component) approach to collect > data to pass to the outsourced payment service. > > Sebastian _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Making a store in Seaside
|
|
In reply to this post by Lukas Renggli
Lukas Renggli wrote:
>> 1. Native handling. I can just say something like: self call: >> SecuredComponent withCart: myCart. and the new object will be >> displayed, it just happens that it's displayed over https (this includes >> a transparent redirect as part of the component). >> > > I would go with this approach. You create a decoration and in > #updateRoot: you change the URL from http to https. Whenever you need > security you add this decoration, whenever you don't you remove it. > This assumes that you have an identical Apache setup for http and > https, but that shouldn't be a problem. > > Lukas Awesome. This sounds easier then I was expecting. Does Komanche/Swazoo/whatever have an https version? Or you meant that it's tunneled through apache somehow? _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: Making a store in Seaside
|
|
> Awesome. This sounds easier then I was expecting. Does
> Komanche/Swazoo/whatever have an https version? Or you meant > that it's tunneled through apache somehow? I do use apache's RewriteRules for that Cheers, Sebastian _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Making a store in Seaside
|
|
Sebastian Sastre wrote:
>> Awesome. This sounds easier then I was expecting. Does >> Komanche/Swazoo/whatever have an https version? Or you meant >> that it's tunneled through apache somehow? >> > > I do use apache's RewriteRules for that > > Cheers, > > Sebastian > > _______________________________________________ > Seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > How does that work exactly? It's not enough that Apache take the URL and turn it into something else, it would have to supply the encryption. Does it do that? Even so, is there a pure Smalltalk web server that can do SSH? _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Making a store in Seaside
|
|
you can aso use stunnel,
http://www.stunnel.org/ quoting: Stunnel is a program that allows you to encrypt arbitrary TCP connections inside SSL (Secure Sockets Layer) available on both Unix and Windows. Stunnel can allow you to secure non-SSL aware daemons and protocols (like POP, IMAP, LDAP, etc) by having Stunnel provide the encryption, requiring no changes to the daemon's code. On 9/12/07, Jason Johnson <[hidden email]> wrote: > Sebastian Sastre wrote: > >> Awesome. This sounds easier then I was expecting. Does > >> Komanche/Swazoo/whatever have an https version? Or you meant > >> that it's tunneled through apache somehow? > >> > > > > I do use apache's RewriteRules for that > > > > Cheers, > > > > Sebastian > > > > _______________________________________________ > > Seaside mailing list > > [hidden email] > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > > > > How does that work exactly? It's not enough that Apache take the URL > and turn it into something else, it would have to supply the > encryption. Does it do that? Even so, is there a pure Smalltalk web > server that can do SSH? > _______________________________________________ > 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 |
RE: Making a store in Seaside
|
|
In reply to this post by Jason Johnson-3
Good news: depending on your choice you may not need to do nothing, or
almost nothing, from smalltalk for this feature to work. Take a look to this: http://leftshore.wordpress.com/2006/10/27/hint-setting-up-apache-proxy-for-y our-seaside-host/ Boris even post an example of an apache VirtualHost. I'm doing a couple of things a little different but it's a good start point for you to get the idea cheers, Sebastian Sastre > -----Mensaje original----- > De: [hidden email] > [mailto:[hidden email]] En nombre > de Jason Johnson > Enviado el: Miércoles, 12 de Septiembre de 2007 16:48 > Para: Seaside - general discussion > Asunto: Re: [Seaside] Making a store in Seaside > > Sebastian Sastre wrote: > >> Awesome. This sounds easier then I was expecting. Does > >> Komanche/Swazoo/whatever have an https version? Or you meant that > >> it's tunneled through apache somehow? > >> > > > > I do use apache's RewriteRules for that > > > > Cheers, > > > > Sebastian > > > > _______________________________________________ > > Seaside mailing list > > [hidden email] > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > > > > How does that work exactly? It's not enough that Apache take > the URL and turn it into something else, it would have to > supply the encryption. Does it do that? Even so, is there a > pure Smalltalk web server that can do SSH? > _______________________________________________ > 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 |
Re: Making a store in Seaside
|
|
Ok, thanks. Though it is my intention not to use apache if there is any
way at all to avoid it. I don't want a stack, but a homogeneous system. I know I can do it in other high level languages, but Seaside is my first choice to try. Sebastian Sastre wrote: > Good news: depending on your choice you may not need to do nothing, or > almost nothing, from smalltalk for this feature to work. > > Take a look to this: > http://leftshore.wordpress.com/2006/10/27/hint-setting-up-apache-proxy-for-y > our-seaside-host/ > > Boris even post an example of an apache VirtualHost. > > I'm doing a couple of things a little different but it's a good start point > for you to get the idea > > cheers, > > Sebastian Sastre > Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Jason,
I use Komanche in Squeak for www.bountifulbaby.com . There is no Apache, and no other http server. It uses stunnel for SSL. However, that site is running an old version of Seaside. I developed another site that ran live from November 2006 until the end of July 2007, using a later version of Seaside. It used Apache, and mod_ssl for SSL. So, I've done it both ways. I would use Apache on any other Seaside sites. In fact, with the later versions of Seaside, Seaside almost requires it. Unless you don't need SSL. I don't recall details, but later versions of Seaside changes the URL rewriting from the old version sufficiently to thoroughly hose the stunnel approach I previously used. I imagine I could have solved the problem somehow, but it was just easier to switch to Apache. Nevin > Ok, thanks. Though it is my intention not to use apache if there is > any way at all to avoid it. I don't want a stack, but a homogeneous > system. I know I can do it in other high level languages, but Seaside > is my first choice to try. > > Sebastian Sastre wrote: >> Good news: depending on your choice you may not need to do nothing, or >> almost nothing, from smalltalk for this feature to work. >> >> Take a look to this: >> http://leftshore.wordpress.com/2006/10/27/hint-setting-up-apache-proxy-for-y >> >> our-seaside-host/ >> >> Boris even post an example of an apache VirtualHost. >> >> I'm doing a couple of things a little different but it's a good start >> point >> for you to get the idea >> >> cheers, >> >> Sebastian Sastre >> > _______________________________________________ > 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 |
RE: Making a store in Seaside
|
|
In reply to this post by Jason Johnson-3
Hi Jason,
I think you can avoid apache by replacing it with a light http server, but if what you want is homogeneity that do not count. You may starting to evaluate other http servers for smalltalk to see if they meet your needs and how much work or not they will guarantee to give to you. I think if you search this list there are some benchmarks comparing comanche, swazoo and apache for file serving. There are some cons for homogeneity in this puntual regard like fault tolerance, security, robustness, etc. and as an http can be pragmatically seen just as a file server for Seaside solutoins I would think large and twice or more times before seting up in production an st http server for everything. But beside that the *big* con of homogeneity in that point cames to you when scalability arrives. And, as far as I know, is an uncontroversial one. cheers, Sebastian Sastre > -----Mensaje original----- > De: [hidden email] > [mailto:[hidden email]] En nombre > de Jason Johnson > Enviado el: Jueves, 13 de Septiembre de 2007 01:50 > Para: Seaside - general discussion > Asunto: Re: [Seaside] Making a store in Seaside > > Ok, thanks. Though it is my intention not to use apache if > there is any way at all to avoid it. I don't want a stack, > but a homogeneous system. I know I can do it in other high > level languages, but Seaside is my first choice to try. > > Sebastian Sastre wrote: > > Good news: depending on your choice you may not need to do > nothing, or > > almost nothing, from smalltalk for this feature to work. > > > > Take a look to this: > > > http://leftshore.wordpress.com/2006/10/27/hint-setting-up-apache-proxy > > -for-y > > our-seaside-host/ > > > > Boris even post an example of an apache VirtualHost. > > > > I'm doing a couple of things a little different but it's a > good start > > point for you to get the idea > > > > cheers, > > > > Sebastian Sastre > > > _______________________________________________ > 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 |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |