[Seaside] Making a store in Seaside

Sebastian Sastre ssastre at seaswork.com
Wed Sep 12 12:05:44 UTC 2007

I'm also was thinking about an 1 (secured component) approach to collect
data to pass to the outsourced payment service.



> -----Mensaje original-----
> De: seaside-bounces at lists.squeakfoundation.org 
> [mailto:seaside-bounces at lists.squeakfoundation.org] 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
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

More information about the seaside mailing list