I’m considering building a registration server in Xojo, I’ve never dabbled in WE so I just have some questions.
#1 Can I build a CGI, I’m not actually looking for a web interface, more of a remote ‘console’ type app.
#2 Would that CGI be compatible with GoDaddy’s servers?
#3 Has anyone done anything like this with Xojo, roughly how hard was it?
I’m just gathering info here, I haven’t even designed the project yet.
Yes, you can use the CGI template. I’m not sure it will run on GoDaddy servers though. You’ll need the 32-bit libraries installed on the server, so that could be an issue. It’s been my experience that GoDaddy cannot handle anything more powerful than a hamster wheel.
You could do so with PHP or some other server-side scripting. That’s what I did for Xojo. Not trying to talk you into one direction or another, just pointing out options.
Thanks Thom, I appreciate the help and suggestions, I know a little PHP, but am more comfortable with Xojo 
Are you looking to replace eSellerate and roll your own e-commerce solution? If so, it can be done with Xojo and the payment processing service of your preference.
It’s something that I’m considering, we also sell through several different partners and bundles. eSellerate’s busting my balls at the moment, as they’re preventing activations from certain countries (for my security), but as one of our apps is in a bundle, customers are purchasing the application and then not able to use it.
So I’m thinking my #1 priority is to use my own registration/activation system, get all new apps over to this system. Then as the apps get cycled the eSellerate store just becomes a store, to which I can dump when I have a newer store set-up without worrying about customers not being able to use their products any more.
I’m even contemplating how viable managing our own store is. Last year our own store accounted for only 15% of our business, while bundles accounted for 24%, with MAS accounting for almost all the rest. I mean once all our apps are cycled and available on MAS + others, is there a need?
The CGI Template will run on godaddy.com’s linux servers. You need to confirm that CGI is enabled with your account.
Thanks Douglas, good to know. I do have a linux account. Apart from enabling CGI support, is there anything else I need to do?
[quote=24518:@Sam Rowlands]It’s something that I’m considering, we also sell through several different partners and bundles. eSellerate’s busting my balls at the moment, as they’re preventing activations from certain countries (for my security), but as one of our apps is in a bundle, customers are purchasing the application and then not able to use it.
So I’m thinking my #1 priority is to use my own registration/activation system, get all new apps over to this system. Then as the apps get cycled the eSellerate store just becomes a store, to which I can dump when I have a newer store set-up without worrying about customers not being able to use their products any more.
I’m even contemplating how viable managing our own store is. Last year our own store accounted for only 15% of our business, while bundles accounted for 24%, with MAS accounting for almost all the rest. I mean once all our apps are cycled and available on MAS + others, is there a need?[/quote]
I’m surprised at those breakdowns.
Should you decide to process your own payments, I found writing code to handle PayPal’s PayFlow Pro system quite easy. This is not the same as accepting PayPal payments, it is a means to accept credit cards directly and let PayPal worry about PCI compliance. This is what the Xojo store uses. You can write the code in Xojo and securely accept payments right within your app should you choose.
Though I think you are right, for that breakdown of sales, rolling a custom store is probably not worth it. I’d likely push in an opposite direction and try to get that 15% you sell directly to purchase from the MAS instead.
Just confirm that the *.cgi file permissions are set to 715 after you upload it.
How about testing a CGI locally, do I get run it in Xojo on one machine and connect to it from another machine?[quote=24528:@Douglas Bober]Just confirm that the *.cgi file permissions are set to 715 after you upload it.[/quote]
Thanks Douglas[quote=24525:@Thom McGrath]Should you decide to process your own payments, I found writing code to handle PayPal’s PayFlow Pro system quite easy. This is not the same as accepting PayPal payments, it is a means to accept credit cards directly and let PayPal worry about PCI compliance. This is what the Xojo store uses. You can write the code in Xojo and securely accept payments right within your app should you choose.
Though I think you are right, for that breakdown of sales, rolling a custom store is probably not worth it. I’d likely push in an opposite direction and try to get that 15% you sell directly to purchase from the MAS instead.[/quote]
The immediate plan is to break free of using eSellerate’s registration and activation system, then we simply upload serial numbers to them (although from what I understand that functionality is currently broken).
Then we could do something like rolling a store that uses PayPal or anyone similar. The key is to break reliance on eSellerate first, then it should open up options for us.
Part of the reason why we still have our own store, is that we have things we can’t sell on MAS. App Wrapper (not Mini) in it’s current incarnation can’t be Sandboxed (although I’ve heard with 10.9 there will be entitlements to help), we also sell source code via our own site, and when a customer purchases, then they get the option to download the code.
Lastly, we still have a loyal customer base who would rather purchase directly from us (I don’t mind as eSellerate’s rates are cheaper than MAS). We tend to sell more of our higher priced products on our own store, where as the cheaper ones sell better on MAS.
I see I’ve answered my own question! Doh!
From reading all the posts about the service issues with other digital rights management service providers, I’ve also decided to take the road less traveled, and build my own system. Will let you know how hard it was, when I’m done 
This is a similar strategy I’ve taken, building a REST API in PHP, with the idea to eventually build a management interface in Xojo WE, that simply connects to the same database, but is completely decoupled from the REST API.
To get myself started, I’ve decided to not completely start from scratch, and rather use SugarCRM Community Edition as a starting point for the core of my system, and then wrap my custom API around SugarCRM.
If there is interest I’m happy to host a standalone server to host a pure XOJO implementation. The only requirement is that a group of Xojo customers are prepared to build & contribute to this app. Not open source, just a group working on a project as partners.
Let’s see how it goes.
‘How hard’ is subjective. In my opinion, already knowing the Xojo language made rolling our own e-commerce solution as a Web app nearly as easy as creating a cross-platform Desktop app. There were some obvious differences and some not so obvious but the bigger hurdle was learning how to interact with PayPal, which wasn’t all that challenging either. Like anything new, it does take time to get up to speed. That said, this was my first Web app.
It serves as a simple single page shop for our products. The page has the look and feel of our WordPress blog/website. Upon selection of a product, the buyer is prompted to enter an optional licensee name and/or coupon code. They are then sent off to a PayPal page to enter their credit card information. We chose not to collect any credit card information, even if it was only to be passed to PayPal and never stored. Once they complete their payment through PayPal, the Web app is notified via PayPal’s Instant Payment Notification system. The Web app generates a software license key based on some of the buyer’s information and emails it to them. When any of our products are run with a license key, the key is validated and usage is tracked by the Web app. We use the tracking information only to determine if a license key is being abused. The Web app also serves as a means to remotely monitor and manage all the PayPal transaction and license key usage activity. Those details are presented using a variety of web pages and are easily sortable and searchable.
It’s a complete solution that meets our needs today. As we add products for different markets, we’ll also provide a more robust shopping experience. The web app runs Stand Alone on one of our headless Linux servers. That may also change in the future but works well for us now.
You may chose to approach this very differently but it can be done with Xojo and with less effort than you might expect. As someone with tremendous Xojo/Realbasic experience, you’ll probably get there more quickly than I did. Whatever path you choose, best of luck to you and feel free to contact me directly for details best not shared on a public forum.
We’ve done some similar things in Xojo apps and web edition. We did a ‘web store’ interface with a desktop app to a web edition store where purchase would be made (in our case through Authorize.net) and then it downloaded the appropriate files to the desktop app). Think iTunes (but not for music).
Contact me offline for more info.
One of the nifty features that I like about eSellerate is the ability to do offline registration. User buys it online but for whatever reason they can’t authenticate through the web (thing government facility), so the app gives them a special code, they go to a computer that does have internet access. They visit a special webpage, input the special code, and they get additional codes to input into the app.
It’s very slow and tedious but it covers all the bases and something that we would want to meet our own and client needs.
Is this a shared server? If so, I would expect issues. Most shared hosts don’t particularly care for Web Edition apps since they continue to run and will see it as a ‘bad app’ and terminate it once it’s been running for too long. Simple web edition apps that run for a few minutes at a time may not be so bad but assume the worse and GoDaddy (or whatever host) terminates your app if the server load is heavy.
I think you’ll be much better off running on a VPS. VPS is more expensive but usually you have more control over everything.
The current products I manage uses a similar licensing system, where the software can be activated through the Internet, but when the client does not have an Internet connection, they call our help-desk, read their code over the phone, and the operator reads back their activation code so that they can activate their product manually. Sounds primitive but is really effective when Internet connections aren’t always reliable.
I’ve also seen systems that uses the same idea with automated SMS (text) messages.
The system described by Bob is definitely very valuable in situations where your clients might not always have a reliable Internet connection (e.g. Africa)… (speaking from personal experience).
A question… I see a lot of posts about eSellerate with very negative commentary about their services. Is their services really that bad, or is their services reliable enough to consider, rather than building a whole new system from scratch?
It took them forever to figure out why their plugin wasn’t working with Real Studio 2012. It turned out to be absolutely nothing to do with the plugin but something do with their dll. Sadly, it took them a LONG time and many appeals from me and others to get any action. To me this says that they’re not committed to Xojo long term.
I’ve not had any connection issues and it’s worked well for me and my customers. I believe Sam had some accounting issues with them which is the main impetus for rolling his own solution.
I’ve been relatively happy with eSellerate. It just works. It’ not onerous for users (most of the time) and it helps control blatant piracy and I get to control how many computers any given license is good for. The web and in-app purchasing is nice as well as the online and offline license validation. They handle all of the money exchange and a bunch of things I just don’t have to deal with. Other than the plugin issue they’ve been responsive to my support needs.
Any system that I would build would have need dedicated support and regular updates and, perhaps more importantly, keep up with the current trends in hacking and cracking licensing and registration schemes. A centralized system provides a focal point for password cracks. So security has to be THE focal point because the last thing any of us want to do is lose money if we happen to hit upon THE app of the decade.
I actually wrote a Linux Console app in Xojo/RB that used the MBS Registration Engine. I have this under test on my year Free Amazon Web Services. Basically I have a PHP page that lives on the AWS server and then simply shell_execs to that console file with some parameters and returns either FAIL or the reg code.
<?
$email = $_GET["email"];
$id = $_GET["id"];
if ($id == "ClockMaker")
{
$url = "/opt/regmaker/RegMaker ".$email." CLOCK";
// $output = $url;
$output = shell_exec($url);
echo $output;
}
This is the simple test right now and will be expanded. I did this before I upgraded to PRO and didn’t have the Web stuff, but I like the simplicity of this.
Hope this thought may help.
I like it. Thanks for posting.