[Seaside] Making a store in Seaside
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?
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
More information about the seaside