Okay, so I understand you use iconCube, and the purchase page requires a domain name. I am in development, and the domain name is not yet decided. Also, once you think about this question, we use multiple domain names for our sites, and change the primary one based on promotion efforts/traffic/hosting arrangements. So the question is... how do you "lock" to a domain name, can it be under user control, how do you respond to the possible need to integrate across multiple domain names (such as when two virtual sites - possibly on different servers - share a database or css or templates? We currently use iconCube ourselves to encrypt database connections and even some sensitive data. Will there be any compatibility problems? Finally, our primary domain may be behind the firewall, serving internally only. As you can see, except for one smal menton in a forum you do not disclose your use of iconCube and while I don't mind *judicious use* there are actually numerous issues related to it's use that ned to be discussed. Thanks.
You're able to request domain name change within first 3 months. During order specify "unknown.com". Domain name is locked seriously, so it will not work on different domain (exception made if your hosting offer you shared SSL certificate on their own domain, then it is possible and will work). I would mention ionCube in requirements, but as you can see now, it causes lot more questions than it should. Sure, it will work, why not? No conflicts at all. Therea are only 2% of customers who may have problems with ionCube, and we're anyway ready to resolve these problems. Firewall doesn't make sense here at all.
what doesn't make sense? Alex said: Firewall doesn't make sense here at all.[/QUOTE] Huh? Not every server is on the Internet. We run a registration system serving dozens of clients plus hundreds of "public" users, and proxy certain traffic to the Internet thru a firewall. Our server running our code is not on the Internet. We change the domain name to suit the event we are supporting. What doesn't make sense to you? I'll consider amember to be just another clever script intended to be sold to the 60% of small-time buyers who don't know anything about apache or otherwise aren't yet wise enough to know better. Thanks for the honest reply.
I'm happy to work with real professionals. When I said that firewall doesn't make sense, I meant that the script doesn't contact external sources (like my server) for everything and that if you will use it inside your local orgranization, it will work without problem. aMember checks if domain name in request matches domain name in license. If there is no match, it will die and display error message. You may use as many subdomains as you wish, but multiple installations of aMember denied by license agreement. I don't understand how license/domain checking question is related with ionCube. What if license/domain checking code wouldn't be encoded? Would you just "hack" it?
hacking Alex said: I don't understand how license/domain checking question is related with ionCube. What if license/domain checking code wouldn't be encoded? Would you just "hack" it?[/QUOTE] -------------------------- I was not aware of the detals of your ioncube use, but I assumed it was as you said - an encryption of the domain name. My concerns about that were with respect to changing the domain name. Yes, we would hack it - probbaly put the domain into a var in base_include and move on. Not much of a hack when you consider it's php and our whole site is php. ioncube concerns were not about domain name, but a few things (some you have answered): - would it conflict with existing use of ioncube (the site is encoded prior to publishing and I personally am not aware of how ioncube stores the keys) - would encrypted code include phoning home (won't work when we deploy on intranet) The bottomline is modules such as yours provide a convenience for maintenance and modularity, worth the price if they are stable, maintained, and easily integrated/dis-integrated (no pun intended). It's very much like hiring you to handle the mod-rewrite, globals, and user auth integration for us. Since it is PHP code and based on the appearance of your activity and support, this is an appealing solution to the user auth problem. However, ioncube and can't-change-domain-name are two very specific and troublesome aspects for these very reasons. Each of these breaks the very value that comes with open source and third party product integration. With such barriers in place, my wisest decision is to sacrifice the attractive user scripts and stability of maintenance and code it ourselves. Sure it's nice to have some enforecment of licensing, but perhaps not wise when it removes the very value your product brings to our projects. Perhaps it's the price to pay for a low product price, as compared to consulting fees.
just to clarify... I reread my message and just want to clarify. When I spoke of the value of Open Source I was not implying that amember follows or should follow an open source model... I respect that is is proprietary license. I was referring to the fact that it is PHP and as such attractive because of the modularity and modify-ability of code (server scripts). As I suspect you are already aware, the more binar your product becomes the less attractive it is unless you can demonstrate a very safe (virus.trojan/spy) and powerful support organization (ala Microsoft, etc). Once you go to binary it is a very, very different world.
First, aMember Pro is not completely encoded. Only 2 small files are encoded, 95% of code is available. Our main goal when we started to encode the script was to stop fraud. After this change and corresponding notifications on pre-sales page, fraud rate changed and now it is 10 times lower than we had. It is why we do it.