Of course, any of your end users can simply go to another resellers site
and edit the domain there if they know the username and password. Perhaps
you don't let them know the opensrs username and password, and just map
passwords in your local database, though.
Personally this is the only method I'd find acceptable, and it is what I
had assumed the system was going to be when I had first tried it out. For
now, I'm in quickstart mode, as I wanted to register a few domains for
myself, and I'm waiting to see what 2.0 has to offer before I go
full-blown. What I'm looking for is:
1) Transfers to/from netsol, register.com, et. al.
2) Transfers between different opensrs resellers.
3) Ability to control all aspects of my end-users domain management,
except for transfers. Everything except transfers must go through my
scripts.
4) Transfers between different individuals within opensrs. This is
accomplished easily given 2 and 3.
5) Ability to freeze all such transfers until payment has cleared.
6) Something resembling NIC-HANDLES, or else I will have to implement
something myself on my end.
7) Some type of ability to cancel domain names within 24 hours with a
refund. Minimally, the ability to cancel an unlimited number of domains
within 24 hours for a fee of no more than $50 total. The only way to
implement this system is live, where the end-user is guaranteed to obtain
the domain after submitting valid credit card information, and while I am
willing to eat the costs of a limited number of fraudulent domain
registrations (where the end-user doesn't get to keep the domain), I must
be able to manually verify suspect orders if, for instance, 1000 of them
come in at once. I'm not willing to lose $10,000 just because some
prankster found 1000 credit card numbers and addresses. Opensrs, of
course would have full discretion to cancel this priviledge for a given
reseller, given reasonable advance warning, if it feels that the reseller
is abusing this priviledge (domain squatting, for instance).
> We do not use reg_system.cgi , we developed our own interface
> directly into opensrs.pl . This allows us to use our existing internal
> domain management system. It's not "stealing" passwords, the customer has
> no knowledge of OpenSRS and would assume the password and other
> information they are entering will be retained by our system. When we
> first looked at OpenSRS we were surprised there was a management interface
> at all on their side. I am of the opinion that this should be a client
> side issue and left up to the implementing service provider. That is the
> point of my diatribe. Although I do agree with you in that, in this case,
> I would also hope to be able to make any modification to any domain
> without restriction. I would want to feel like a registrar, like I am
> connecting right into the NSI registry with all the capabilities therein.
>
>
> Jeff
>
>
>
This archive was generated by hypermail 2.1.3 : Tue Oct 19 2004 - 23:35:23 EDT