[Seaside] Making a store in Seaside
Jason Johnson
jbjohns at libsource.com
Wed Sep 12 05:48:23 UTC 2007
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
More information about the seaside
mailing list