Bekijk Volledige Versie : [TE KOOP] DRS5 EPP Client voor SIDN
Beste WHT-ers,
Met grote trots kunnen wij melden dat de QuickEPP DRS5 client productiegereed is. De vele tests die afgelopen periode door SIDN deelnemers gedaan zijn hebben veel positieve uitbreidingen en verbeteringen opgeleverd. De software werkt goed en houdt rekening met de Acceptable Use Policy van SIDN.
Belangrijk om te weten is dat we de verschillende versies die we initieel aanboden hebben samengevoegd tot 1 versie: de grootste variant. Hierdoor is het versiebeheer van de software transparanter en de animo voor het systeem zonder bulkopties was vrijwel te verwaarlozen.
Enkele sterke punten van QuickEPP:
-> up-to-date blijven over verhuizingen; volledig inzichtelijk en ieder moment status updates mogelijk
-> de zogenaamde poll queue wordt geautomatiseerd uitgelezen en verwerkt
-> bulk: opheffingen, registraties, authcodes opvragen, verhuizingen, domeinhouder wijzigen, domein admin wijzigen, domein techs wijzigen, nameservers wijzigen.
-> domein whois geintegreerd: dit is de nieuwste versie van de whois op basis van het IRIS protocol
-> domein info: op ieder moment van de dag domeinnaam info ophalen en controleren
-> contactpersonen beheer: na de verhuizing van een domeinnaam vertelt onze EPP-client aan u of tijdens de verhuizing bestaande contactpersonen zijn gekoppeld of dat SIDN nieuwe contactpersonen heeft aangemaakt. U kunt dan kiezen om na de verhuizing nog een houderwijziging uit te voeren.
-> contactpersonen beheer: vrije input. Ieder land heeft zijn eigen vereisten, dit is mogelijk met onze client.
-> goede input validatie en goede logging: vrijwel ieder probleem kan opgelost worden alvorens de aanvraag naar SIDN verstuurd wordt.
-> domeinregistratie: bulk registratie met bulk beschikbaarheidscontroles mogelijk. Optioneel te configureren in de client.
-> nameservers: zelf nameservers aanmaken en beheren. Ook buitenlandse nameservers (ns1.googledns.com) e.d. kunnen in onze client geimporteerd en gebruikt worden.
-> volledige synchronisatie van contactpersonen, nameservers (hosts), en glues (inclusief ip-adressen) na een succesvolle verhuizing.
-> nog veel en veel meer!
Demo:
U kunt een demo bekijken op twee locaties, waarvanuit u dus ook verhuizingen kunt testen:
http://beta2.directwebsolutions.nl/quickepp/
http://beta2registrar2.directwebsolutions.nl/quickepp/
In de demo omgeving is helaas geen taakmanager op de achtergrond geconfigureerd waardoor uitgaande verhuizingen helaas niet in het overzicht van de latende deelnemer komen te staan. Wel kan de status van zichtbare verhuizingen (die niet asynchroon zijn aangevraagd) handmatig worden bijgewerkt d.m.v. de knop aan het eind van de regel.
De login voor beide systemen is hetzelfde:
Gebruiker: demo@localhost
Wachtwoord: demodemo
Bestellen:
Om de software te bestellen dient u mij een akkoord te geven per email met daarbij uw bedrijfsnaam, naam van de contactpersoon, volledig adres, emailadres en telefoonnummer. Voor het gebruik van de software zal een gebruikersovereenkomst worden toegestuurd, waarna de verdere afhandeling plaatsvindt. Hulp bij de installatie en migratie van uw huidige domeinnamen bestand is hierbij inbegrepen.
Meer informatie staat op http://www.directwebsolutions.nl/diensten/sidn-epp-communicatielaag-en-drs-systeem.html . Bestellen kan ook direct door een email te sturen naar info@directwebsolutions.nl
Met vriendelijke groet,
Tim Boormans
Direct Web Solutions
Goed, topic schoongemaakt, nu ontopic, dit is een verkoop topic, discussie over de werking moet of via PM of ergens in een ander topic... als ik teveel verwijderd heb zet het zelf maar weer even terug het was nu iig niet meer overzichtelijk...
@Berrie: je hebt nu ook andere relevante info weggehaald...
- Prijs: 249 euro excl 19% btw.
@Tim: Heb je voor ons wat informatie aangaande mogelijke updates/bug fixes? En wat wanneer SIDN weer eens een update uitvoert? Worden deze zaken tijdig verwerkt in DRS EPP en krijgen alle klanten dan een update? Of moeten we voor updates betalen in de toekomst?
Is het systeem OOP of PP geprogrammeerd? Wil dit graag weten alvorens aanschaf i.v.m. gebruik en eigen aanpassingen. Ik denk dat dit voor andere partijen ook nuttige informatie kan zijn.
@Bob, wat versta je onder PP? Plain PHP misschien? Aangezien ik er nog nooit van gehoord heb zal het zeer waarschijnlijk OOP zijn ;) Er zijn een 6tal klassen boordevol functions, en de communicatielaag is puur functions zonder klassen. Dat is express gedaan om het simpel te houden voor mensen zonder veel verstand van PHP.
@adknoth: Zelf gebruiken we ook het paneel. Een error voor jullie is ook een error voor mij. Zoals gezegd krijg je in den beginne de fixes gratis, en zoals we overleggen in de email zitten er ook gewoon wijzigingen in die momenteel beter kunnen.
Niet geheel onbegrijpelijk is het onhaalbaar om de komende 10 jaren een product te gaan ondersteunen aan XX partijen zonder er ooit nog maar geld voor te vragen. Dus daarop is mijn antwoord: Ja, in de toekomst zul je abonnement moeten afsluiten om product updates te blijven ontvangen. Dit zal zeer waarschijnlijk op jaarbasis gaan, en circa 17,50 euro per maand kosten.
Ik denk echter dat 17,50 euro kleingeld is als je het vergelijkt met het voor, laat zeggen 2 klanten per maand, een wijziging door de webinterface moet muteren. Dan heb je die kosten al dik eruit en heb je nog heldere tool over voor de rest van de maand.
Ber|Art edit: volgens mij was ik heel duidelijk: ontopic!!
Ber|Art edit: volgens mij was ik heel duidelijk: ontopic!!
- Prijs: 249 euro excl 19% btw.
Ja, in de toekomst zul je abonnement moeten afsluiten om product updates te blijven ontvangen. Dit zal zeer waarschijnlijk op jaarbasis gaan, en circa 17,50 euro per maand kosten.
Ik zou graag van te voren weten waar ik aan toe ben....
Het is inderdaad door tijdsdruk niet volledig volgens de richtlijnen van 'perfecte programmatuur' in elkaar gezet. Wel of niet kopen om die reden zal ik absoluut niet tegenin gaan. Mijn klanten zijn voornamelijk mensen die zelf niet kunnen programmeren en graag aan de slag willen met een client tool.
@Geert: ik snap je reactie volledig. Ik zal e.e.a. uitmeten en publiceren deze week.
Zonder verder tegen argumenten in te gaan wil ik graag nog iets toevoegen aan mijn reactie:
Er waren verhitte reacties over het gebruik van register_globals. De applicatie zou hierdoor onveilig worden. Ik kon niet begrijpen waarom, en daarom heb ik vanavond aan de vooravond van oplevering nog eens even goed erin gedoken en ben tot een goede conclusie gekomen. Je mag me corrigeren als ik het fout heb trouwens, maar laten we het netjes houden.
Er zijn een behoorlijk aantal mensen die $GLOBALS gebruiken om hun hele applicatie mee te configureren. Dat zijn dezelfde mensen die ook met globals in functions werken en die $GLOBALS voor includes en alle andere variabelen gebruiken. Ik beweerde echter dat mijn applicatie daar geen last van heeft, maar dat kreeg om de 1 of andere reden niet hard gemaakt. Daarom wil ik de situatie graag uitleggen.
In mijn QuickEPP script heb ik maar op 1 plaats gebruik gemaakt van de register_globals, en dat is binnen de zogenaamde 'base' klasse. Op de base klasse zijn alle andere klassen gebaseerd. Ik vind het altijd een prettig idee om maar 1 pointer te hebben naar een openstaande mysql verbinding (al maakt dat in PHP amper iets uit), en daarom stop ik de pointer naar het database object in een global. Dat de database verbinding niet in de base klasse zit heeft met het uitvoeren van de constructor te maken. De constructor van de base klasse zal nooit uitgevoerd worden, en ik heb geen zin om op dat soort dingen uren zitten debuggen omdat ik de fout niet vind 'in het geval dat'. Dat is meer een voorkeur die iedere programmeur anders zal ervaren. Over het algemeen betekent het dat je met GLOBALS de database verbinding zou kunnen hijacken, maar ook al ben ik geen expert om te zeggen of het nou wel of niet zo is, weet ik wel dat ik werk met een configuratie bestand. Dus in de database klasse zijn geen parameters in de connect function en er zijn ook geen inloggegevens hardcoded als klasse variabelen en ook geen gebruik van GLOBALS, maar hij laadt de verbindings instellingen uit het config.quickepp.php bestand op een andere locatie. Die locatie is relatief geprogrammeerd (niet absoluut en niet met GLOBALS of een andere variabele in de pathnaam), en daar kan dan ook niets on runtime aan gewijzigd worden. Als ik over die werking zou moeten oordelen in de gedachte van XSS zou ik geneigd zijn te zeggen dat er aan de database verbinding niet veel te hijacken valt.
De rest van de hele applicatie werkt gewoon netjes met $_POST, $_GET en $_COOKIE. Nergens gebruik ik globals, zelf niet in functions.
Als extra security through obsecurity werkt de applicatie met mooie URL's. Die URL's worden door een klasse genaamd 'skin' opgehaald en verwerkt indien het Get waarden zijn (altijd natuurlijk). Post waarden worden met $_POST opgehaald en beveiligd/gecontroleerd.
Graag hoor ik van de mensen die hierover gereageerd hebben of ze na het lezen van deze informatie nog steeds van mening zijn dat mijn applicatie zo lek als een zeef is. En zo ja, wat scheelt er dan nog aan?
- Prijs: 249 euro excl 19% btw.
Ik zou graag van te voren weten waar ik aan toe ben....
@Geert-Jan: ik heb vandaag de website van QuickEPP volledig ingericht en daarbij ook duidelijkheid verschaft over de regeling van updates en de kosten daarvan. Neem eens een kijkje op: http://www.quickepp.nl/bestellen/
Overigens staat er ook nog veel andere informatie uitgebreid op beschreven die enorm handig is voor de mensen die geïnteresseerd zijn in de tool: http://www.quickepp.nl/
Okay, weet dat de volgorde waarin variabelen worden gedefiniëerd 'EGPCS' (ezelsbruggetje) is: Environment - Get - Post - Cookie - Server. M.a.w. probeer eens:
$bla='1';
$bla=$_GET['bla'];
echo($bla);
Roep het script eens aan met script.php?bla=2 en kijk nu eens wat je op je scherm vindt.
Dat is het hele eieren eten. Door register_globals te activeren kun je de values die her en der door je script zijn gezaaid aanpassen op een manier waar niemand op zit te wachten. Neem dan het volgende voorbeeld (van php.net:
<?php
// define $authorized = true only if user is authenticated
if (authenticated_user()) {
$authorized = true;
}
// Because we didn't first initialize $authorized as false, this might be
// defined through register_globals, like from GET auth.php?authorized=1
// So, anyone can be seen as authenticated!
if ($authorized) {
include "/highly/sensitive/data.php";
}
?>
En dat is nog maar één ding. Je kunt bijvoorbeeld ook lui hebben die ineens commando's gaan injecten via een brakke variabele.
---
Als extra security through obsecurity werkt de applicatie met mooie URL's. Die URL's worden door een klasse genaamd 'skin' opgehaald en verwerkt indien het Get waarden zijn (altijd natuurlijk). Post waarden worden met $_POST opgehaald en beveiligd/gecontroleerd
Ja, dat is opzich goed omdat je dan de kans niet geeft om variabeles te vervormen. Als je alle input maar laat controleren is er niets aan de hand.
Maar wat doe je als PHP6 uitkomt?
Dus als ik het goed begrijp zit het nu op zich wel goed, maar zou het beter zijn als ik voor de database verbinding geen GLOBAL gebruik maar een DEFINE. Ook al is er niets inhoudelijk aan de databaseverbinding te wijzigen, maar puur omdat het eventueel zo zou kunnen zijn dat op een andere plek wel iets te overschrijven is? (ook al gebruik ik nergens GLOBAL's)
Je voorbeeldcode snap ik, maar dat lijkt me ook normaal. Ik ben eigenlijk niet anders gewend dat de code zo werkt.. Mijn vraag is dan: ik werk nergens met:
<?php if($getwaarde == "iets") { } ?>
Maar overal met code zoals:
<?php
$var = "iets";
if($_GET['waarde'] == "iets-anders") {
$var = $_GET['waarde'];
}
(even uitgaande van een simpele get zonder een $skin->segment(x); aanroep natuurlijk.
Is er dan wel iets onveilig aan?
Het lijkt erop dat ik register_globals helemaal niet nodig heb om het script te draaien. Ik ben er vanuit gegaan dat ik die wel nodig zou hebben, maar aangezien er niets te registeren valt zou het ook niet nodig hoeven zijn. Aldus een anonieme tipgever ;)
Dus als ik het goed begrijp zit het nu op zich wel goed, maar zou het beter zijn als ik voor de database verbinding geen GLOBAL gebruik maar een DEFINE. Ook al is er niets inhoudelijk aan de databaseverbinding te wijzigen, maar puur omdat het eventueel zo zou kunnen zijn dat op een andere plek wel iets te overschrijven is? (ook al gebruik ik nergens GLOBAL's)
Juust, register_globals maakt eigenlijk dat je met een beetje pech alle variabelen via de adresbalk kunt aanpassen. Daar zit je natuurlijk niet op te wachten.
Je voorbeeldcode snap ik, maar dat lijkt me ook normaal. Ik ben eigenlijk niet anders gewend dat de code zo werkt.. Mijn vraag is dan: ik werk nergens met:
<?php if($getwaarde == "iets") { } ?>Maar overal met code zoals:
<?php
$var = "iets";
if($_GET['waarde'] == "iets-anders") {
$var = $_GET['waarde'];
}(even uitgaande van een simpele get zonder een $skin->segment(x); aanroep natuurlijk.
Is er dan wel iets onveilig aan?
Zo krijg je in ieder geval niet dat iemand je code afbreekt door ");" te injecten en zijn eigen ding te doen (zie je vaak bij zelfgeprutste contactformuliertjes die afhankelijk zijn van register_globals). De variabele blijft dan echt een variabele en geen random input; jij bepaalt precies wat wel en wat niet als variabele gebruikt kan worden. Een buitenstaander kan nog wel analyseren hoe je script in elkaar zit door verschillende waardes voor $var te proberen, maar dat zou geen kwaad moeten kunnen.
Overigens, als alles zo in elkaar steekt dat jij zaken definieert met $_GET, dan ben heb je register_globals inderdaad helemaal niet nodig en heeft je anonieme tipgever (hoestende man in een donker steegje met lange regenjas?) gelijk.
Ten slotte: veel succes met je project, ziet er goed uit!
Heel erg bedankt voor al je comments meneer met nickname Cybafish! ;)
Ik heb zojuist de register_globals uitgeschakeld en de boel werkt perfect, goede toevoeging van jullie allemaal dus! Fijn dat het nog even goed uitgepraat is want er begonnen al wat klanten zenuwachtig te worden.. ;(
ALs ik je eerste verhaal lees lijkt het me dat je een variable global maakt in je hele script mhv het global keyword? Dat is iets anders dan register_globals aan hebben staan.
Register globals maakt namelijk van alle externe "variabele", globale variabelen.
In principe zou register_globals altijd uit moeten staan. Werken met het global keyword kan af en toe zeker handig zijn, en niet super veel kwaad als je het maar netjes doet.
Echter wil je op een juiste (best practice) manier dit voor elkaar krijgen dan moet je werken met een class met singleton structuur.
Zie ook: http://nl.wikipedia.org/wiki/Singleton_%28informatica%29
Ik heb echt waar, niet gelogen, die tip al van heel veel verschillende mensen gekregen. Ik ben iemand die hoofdzakelijk naast PHP met .NET werkt en daar heb je eerder andere zaken waar je op doet letten. Je maakt daar gewoon 1 instantie van een DAL aan (bijvoorbeeld iBatis) en die blijf je hergebruiken door je hele applicatie heen.
Singleton in PHP is inderdaad veel van hetzelfde en die zal ik in de toekomst dan ook gaan gebruiken.