Ik probeer het mogelijk te maken dat een website die zich elders bevindt bepaalde gegevens uit mijn database kan ophalen, tot nu toe zonder het gewenste resultaat want de website kan geen verbinding maken ( Can't connect to MySQL server)
Dit is wat ik heb gedaan:
1.
mysql> GRANT SELECT ON mijndatabase.mijntabel TO nieuwegebruiker@’ipadres-van-externe-website’ IDENTIFIED BY ‘wachtwoord’;
2. open port 3306 mysql
sudo iptables -A INPUT -p tcp -s 0/0 --sport 1024:65535 -d ipadresexternewebsite --dport 3306 -m state --state NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -p tcp -s ipexterneadreswebsite --sport 3306 -d 0/0 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT
config van *.php pagina op de externe website die contact gaat maken met mijn server
Het zijn gestandaardiseerde gegevensformaten die je kan gebruiken om data gestructureerd uit te kunnen (laten) lezen. Bij een API bepaalt de gebruiker welke data hij ophaalt. Dit kan door middel van een (GET-)parameter in de URL zijn, of een POST-parameter. Zo beslis je wat iemand uit mag lezen. Je kan ook authenticatie aan API's toevoegen.
Ze kunnen dan gewoon je hele database doorspitten. En dat is niet waar je op staat te wachten.
Niet per definitie: wanneer je een GRANT SELECT ON [tabelnaam] geeft kan alleen op de genoemde tabel geselecteerd worden. Dat bespaart je dan weer het bouwen van een API. Makkelijk wanneer het slechts om 1 andere site gaat en niet om een algemeen beschikbare API. Wil je slechts enkele velden van die ene tabel beschikbaar stellen dan kan je ook nog een keer een view maken op die tabel en die beschikbaar stellen. MySQL CREATE VIEW
Ik ben wel geinteresseerd om een api te maken maar hpoe doe je dat, waar begin ik? (ik had eerst wat gestoeid met curl) maar mijn website heeft auth. en ik kreeg het niet voor elkaar.
Ik heb geen ervaring met het bouwen van een API maar moest toevallig vorige week voor een site gegevens van de RDW via hun API ophalen. Dat doe je via een link. Als je bijvoorbeeld informatie van een voertuig op kenteken wilt ophalen dan gebruik je deze link: https://opendata.rdw.nl/resource/m9d7-ebf2.json?kenteken=95NHNB
Als je hem gewoon in je browser plakt dan zie je wel wat je terug krijgt.
Je geeft een gebruiker op een gecontroleerde manier gegevens uit een database die je op zo'n manier aanbied (JSON of XML) dat de gebruiker deze weer verder kan verwerken.
In dit geval zit er achter de link een script dat verbinding maakt met de database, de rij selecteerd die als kenteken 95NHNB heeft (die via $_GET uit de url gehaald wordt) en alle informatie die de gebruiker te zien mag krijgen vervolgens teruggeeft. De gebruiker kan hier dus niet zelf bepalen welke kolommen hij selecteerd, dat doet de API.
Je kan hierbij ook nog gebruik maken van extra authorisatie, een token wat je controleerd.
Ik heb een goeie handleiding gevonden over Curl (http://www.hackingwithphp.com/15/10/2/your-first-curl-scripts) die stap voor stap uitlegt hoe of wat. Ben er nog steeds mee aan het experimenteren ...
Ik kan met Curl toch doen wat ik wilde zonder dat ik databasetoegang hoef te geven. Ik weet niet of dit bedoeld werd met een api bouwen? Ik ben wel weer wat wijzer geworden
Als je een API bouwt heb je aan de API kant niets te maken met curl. Een API is in feite niet meer of minder dan een php script dat gegevens kan verwerken en uitpoepen.
Ik zit nog met 2 vragen:
Mijn website is https en heeft basic auth. maar de website die een pagina gaat curlen uit mijn website is nog http.
1. Is het veilig als ik dit invul op die http pagina?
2. Sommige images worden geladen op de http website en het slotje van de curlpagina op mijn https website (die linkjes heeft naar die images) zegt nu "de verbinding is niet beveiligd", sommige onderdelen kunnen door anderen bekeken worden. Hoe gevaarlijk is dit? Die fotos zijn toch al openbaar te zien op die andere website. Loopt mijn site toch risico op een of andere manier?
Op de eerste vraag: dat levert geen problemen op.
Op nummer 2: wanneer je https gebruikt dien je ALLE verkeer over https te laten lopen. Images, scripts, css, the works. Wanneer je dit niet doet kunnen requests naar plaatjes e.d. onderschept worden en eventueel worden herschreven. https is niet alleen het versleutelen van verkeer, maar ook het garanderen van de identiteit van de server.
Over puntje 2: Als je maar iets toont binnen je https-omgeving dat naar het onversleutelde http-protocol leidt, dan zal dat door je browser afgestraft worden met een "Mixed content" melding, en zal je groene slotje op dat moment eventjes anders worden in je browser. Afbeeldingen worden nog wel gedoogd, maar ik meen dat javascripts en ik dacht zelfs dat CSS ook geblokkeerd werden.
Een nadeel is dat als je bijvoorbeeld een website hebt waar mensen hun eigen content op kunnen plaatsen (denk aan een forum), dat alle plaatjes waarnaar ze eventueel verwijzen ook daadwerkelijk https moeten zijn. Je zult dus op dit moment ook moeten controleren op het protocol.
Ikzelf heb hiervoor een Camo-proxy gevonden die http plaatjes in een proxy doorgeeft naar een https-verbinding. Het enige wat je nodig hebt is een eigen server hiervoor.
Als ik binnenkort tijd heb zal ik eens kijken of ik een simpele handleiding kan schrijven in de vorm van een tutorial.
