Website online stellen

Xanta schrieb:
Mit 40€ kommst du da übers Jahr mit inlimitierten Webspace aus und ein MySql Server ist auch dabei ;)

Für jemdanden der gerade anfängt sich mit der Materie zu beschäftigen, ist das doch ein wenig teuer. Es gibt noch wesentlich günstigere Angebotem, die teilweise sogar unter einem 1€ pro Jahr liegen. Dort hat man dann zwar nur 500MB oder 1GB Webspace, aber das sollte für kleine Spielereien wohl reichen.
 
sasdensas schrieb:
Zum rumexperimentieren reicht XAMPP auf dem lokalen Rechner. Die paar ct würde ich nicht sparen. Freehoster kannste getrost meiden.
XAMPP ist ausdrücklich NICHT für Live-Systeme gedacht, sondern nur für Testumgebungen. Lies mal die Dokumentation von XAMPP.
Der Hintergrund:
1.) die XAMPP-Installation enthält keine Sicherheits-Einstellungen, die bei anständigen Servern üblich sind
2.) der XAMPP-Apache läuft mit den Privilegien des startenden Nutzers, teilweise sogar mit Admin-Privilegien. Auf einem echten Linux-Server ist das nur bei wirklich räudigen Konfigurationen der Fall, regulär läuft jeder Dienst auf einem hochgradig eingeschränkten User.
3.) die phpMyAdmin - Installation von XAMPP läuft ohne Passwort. Klar, kann man ändern... aber wenn mans vergisst ist man gekniffen
4.) mir ist da keine Möglichkeit für VHosts oder SSL bekannt...

Um mal schnell unter Windows an einem PHP-Script zu arbeiten oder etwas in einer MySQL-Datenbank zu probieren ist XAMPP toll. Für alles, was den eigenen Router nach außen verlässt ist XAMPP absolutes No-Go!

hubertus1990 schrieb:
Einige Apps von mir beziehen und senden Daten (Statistiken) von und an einen Server.
In dem Aspekt kannst du dich vom Heim-Hosting schon einmal verabschieden, denn es ist ökologischer und okönomischer Selbstmord. Ich glaub, selbst eine Raspberry Pi (+USB-Platte mit externem Strom) als Webserver würde wohl mehr Stromkosten erzeugen, als du für einen günstigen Hoster bezahlst.

The_1st_Knight schrieb:
Für jemdanden der gerade anfängt sich mit der Materie zu beschäftigen, ist das doch ein wenig teuer. Es gibt noch wesentlich günstigere Angebotem, die teilweise sogar unter einem 1€ pro Jahr liegen. Dort hat man dann zwar nur 500MB oder 1GB Webspace, aber das sollte für kleine Spielereien wohl reichen.
Ja, aber man kann aber auch gleich Nägel mit Köpfen machen und sich eine ordentliche Domain dazu besorgen. Wie gesagt, so im Bereich von 1-2€ im Monat gibts ordentlich Platz, PHP, MySQL, evtl. noch Python, Ruby & Perl und eine Second-Level-Domain.
 
Daaron schrieb:
Ja, aber man kann aber auch gleich Nägel mit Köpfen machen und sich eine ordentliche Domain dazu besorgen. Wie gesagt, so im Bereich von 1-2€ im Monat gibts ordentlich Platz, PHP, MySQL, evtl. noch Python, Ruby & Perl und eine Second-Level-Domain.

Bei savando.de gibts aber auch schon Einsteigerangebote für 60 Cent im Jahr. Und da ist eine .de-Domain schon mit dabei. Und es gibt bestimmt noch mehr Angebote dieser Art.
 
60ct? für ne de? das is übel... das nenn ich mal quersubventionierung. bei der denic direkt zahlste bestimmt das 12fache...
 
Hab jetzt mal alles bei ohost aufgestetzt, und es funktioniert auch soweit sehr gut.

Habe dort jetzt auch meine .php scripts liegen und mir eine SQL Datenbank erstellt.

Allerdings habe ich noch bedenken wegen der Sicherheit:

- Jeder der die Internetadresse der .php Scripts kennt kann diese ausführen und durch eines der Skripts (das, das die Daten an das Android Gerät sendet) auch alle Daten die in der Datenbank gespeichert sind einsehen. Kann man das irgendwie vermeiden?

- In den .php Scripts sind natürlich auch die Zugangsdaten (Username, Passwort) zur SQL Datenbank gespeichert (da diese ja vom Script verwendet werden). Ist es möglich, diese Skripts, wenn sie online sind einzusehen? Oder brauche ich mir deswegen keine Gedanken machen?
 
hubertus1990 schrieb:
- Jeder der die Internetadresse der .php Scripts kennt kann diese ausführen und durch eines der Skripts (das, das die Daten an das Android Gerät sendet) auch alle Daten die in der Datenbank gespeichert sind einsehen. Kann man das irgendwie vermeiden?
Du könntest den Aufruf der Seite nur zulassen wenn z.B. bestimmte GET- oder POST-Parameter mit verschlüsselten Informationen mitgeschickt werden. Oder du könntest nur bestimmte User Agents zulassen. Wenn du beides kombinierst reicht das für den Anfang.

Die Ausgabe der Datenbank könntest du auch noch verschlüssen, so dass, selbst wenn es jemand schafft, dieser jemand nichts mit den Daten anfangen kann.

hubertus1990 schrieb:
- In den .php Scripts sind natürlich auch die Zugangsdaten (Username, Passwort) zur SQL Datenbank gespeichert (da diese ja vom Script verwendet werden). Ist es möglich, diese Skripts, wenn sie online sind einzusehen? Oder brauche ich mir deswegen keine Gedanken machen?
Niemand kann den rohen Inhalt der .php Dateien einsehen, außer irgendjemand hackt dir den FTP-Zugang. Ich erstelle immer in einem globalen File einfach den Datenbanklink, welcher überall verwendet wird, der wird direkt vom Server kompiliert und die PWs kann da keiner sehen:
PHP:
$db_link = mysqli_connect("localhost", "root", "pw", "db");
 
hubertus1990 schrieb:
- Jeder der die Internetadresse der .php Scripts kennt kann diese ausführen und durch eines der Skripts (das, das die Daten an das Android Gerät sendet) auch alle Daten die in der Datenbank gespeichert sind einsehen. Kann man das irgendwie vermeiden?
Nur, indem du ein paar komplexe Authorisierungs-Abfragen baust. Du könntest z.B. mit der .htaccess den Zugriff auf deine "punktezahl.php" streng limitieren. Nur wer vorher korrekten Usernamen+Passwort schickt darf Punkte eintragen.

- In den .php Scripts sind natürlich auch die Zugangsdaten (Username, Passwort) zur SQL Datenbank gespeichert (da diese ja vom Script verwendet werden). Ist es möglich, diese Skripts, wenn sie online sind einzusehen? Oder brauche ich mir deswegen keine Gedanken machen?
Nicht, wenn der Server aktuell ist. Wenn er hingegen noch von der Sicherheitslücke betroffen is, die im Frühling bekannt wurde...
Ruf mal eine deiner PHP-Dateien direkt auf und häng hinten "?-" (ohne Anführungsstriche) dran. Wenn du jetzt Quellcode siehst, dann tritt dem Hoster derbst in die Glocken.
 
@ Daaron:
Huch, von welcher massiven Lücke sprichst du da? ô.O
 
@blu3r4y: Also der .php Code den du gepostet hast, sieht bei mir genauso aus. Das sollte dann schon ok sein.

Wie genau genau funktioniert es, dass ich den Aufruf einer Seite nur durch get und post Parameter zulasse?

@Daaron:
also wenn ich "?-" anhänge, sehe ich keinen Quellcode, sondern wie gesagt nur den Datenbankinhalt :)
--> das .php Script gibt den inhalt mittels print(json_encode...) zurück
 
Naja, GET-Parameter wäre das allereinfachste. Dabei kannst du z.B. einfach so Parameter mitschicken:

http://www.host.com/script.php?username=root&password=test

Im PHP Skript fragst du dann diese GET-Parameter folgendermaßen ab: (Beispiel)
PHP:
if (isset($_GET['username']) && isset($_GET['password'])
    && $_GET['username'] == "root" && $_GET['password'] == "test")
{

    // Authentifizierung erfolgreich ... (Script starten)

}

Mit POST funktioniert es ähnlich, hier fragst du z.B. die Variablen $_POST['username'] und $_POST['password'] ab. $_GET und $_POST sind jeweils globale Arrays welche alle übergebenen GET- bzw. POST-Parameter beinhalten.

POST-Parameter übergibst du aber anders als GET-Parameter. Da musst du schauen wie die konkrete Umsetzung für deine Android App aussieht. GET wäre für dich somit das einfachere, weil du die Daten nur an die URL dranhängen müsstest. POST verwendet man eher bei größeren zu sendenden Datenmengen.


Und den User Agent könntest du auch noch überprüfen, den liest du aus mit $_SERVER["HTTP_USER_AGENT"]. Da musst du auch wieder schauen wie du in deiner App den User Agent modifizieren kannst. Dafür gehört der HTTP Header modifiziert. Und dann lässt du serverseitig nur einen bestimmten User Agent zu, somit kann man (ohne bestimmte Addons) aus einem normalen Browser heraus die Scripts erstmal nicht ausführen lassen.
 
blu3r4y schrieb:
@ Daaron:
Huch, von welcher massiven Lücke sprichst du da? ô.O
Ach, PHP hatte n großes Oops gebaut. Es betraf zum Glück wenn ich mich richtig erinnere nur CGI und evtl. auch FastCGI, nicht mod_php oder mod_suphp. Daher war der tatsächliche Schaden eher dünn.
Der Fehler war irgendwo in der Behandlung von Parametern, manches wurde wohl direkt an den Parser durchgeschleift, was ihn gar nicht erreichen darf. Wenn du jetzt auf einem betroffenen System index.php?- aufgerufen hast, dann sahst du den Sourcecode der index.php. Was das bei nem Aufruf einer config.php bewirkt is klar. Über andere Parameter konnte man auch gezielt Fremdcode in den Parser einschleusen und damit direkt das System großflächig kompromittieren.

blu3r4y schrieb:
Naja, GET-Parameter wäre das allereinfachste. Dabei kannst du z.B. einfach so Parameter mitschicken:

http://www.host.com/script.php?username=root&password=test
Keine gute Idee. Klar, auch ein POST-Request überträgt das Passwort im Klartext, aber immerhin steht es dann nicht im serverweiten access.log drin.
Besser wäre eh Session Handling. Jede App zündet einmalig einen Login (z.B. überträgt sie per POST eine AppID an das Script) und erhält dafür eine Session-ID (für einige Stunden, Tage,...).

POST-Parameter übergibst du aber anders als GET-Parameter. Da musst du schauen wie die konkrete Umsetzung für deine Android App aussieht. GET wäre für dich somit das einfachere, weil du die Daten nur an die URL dranhängen müsstest. POST verwendet man eher bei größeren zu sendenden Datenmengen.
Die Wahl zwischen POST und GET unterliegt eher weniger den Datenmengen als Betrachtungsweisen, WAS übertragen werden soll.

GET ist eher dazu gedacht, eindeutige Ressourcen anzusprechen. Wenn du 2x dieselben GET-Parameter überträgst, dann kommt im Idealfall beide Male dasselbe raus. Genauso kannst du einen Link mit GET-Parametern auch jemand anderem schicken. Wenn er den Link aufruft wird er idealerweise dasselbe sehen wie du. Ausgenommen sind natürlich personalisierte Inhalte der Seite bzw. Sachen, die einer Rechtebegrenzung unterliegen. aber wenn ich meinmaildienstleister.tld/index.php?site=inbox aufrufe, dann will ich garantiert im Posteingang landen und ihn auch bookmarken können. Mit einem POST-Request auf site=inbox gehts nicht.

POST ist eher dafür gedacht, Inhalte einmalig zu manipulieren. Formulare sind ein gutes Beispiel. Während man bei einer Suche GET nimmt (da hier eindeutige Daten abgerufen werden) wird man bei einem Foren-Beitrag POST nehmen. Ansonsten würde oben in der Adresszeile der ganze Beitrag stehen und, wenn man 4x Enter drückt, der Beitrag auch 4x Mal abgeschickt.
 
Danke für die Hilfe.
Habe das ganze jetzt mal mit "GET" realisiert, ich denke das reicht dicke für meine Sicherheitsanforderungen :)

Ist ja nicht so das ich ein Hochsicherheitsgefängnis betreibe. Es soll halt nicht unbedingt gleich jeder dahergelaufene die Daten einsehen können. Wenn er das App downloaded und in die Statistik sieht sieht er die Daten ohnehin :)

Wenn ich das richtig verstanden habe steht das "passwort" bei der verwendung von GET im serverweiten access log? Ich denke auch das ist dann für meine Anforderungen relativ egal oder?


Sodala... App habe ich auch schon soweit umgeschrieben, ich denke mal in einigen Tagen kann mal ein Update im PlayStore durchgeführt werden :)
Das Game steht jetzt schon zum Download, allerdings noch in der alten Version die Statistiken und Playerscores nur lokal am Gerät speichert.
 
Zuletzt bearbeitet:
hubertus1990 schrieb:
Danke für die Hilfe.
Habe das ganze jetzt mal mit "GET" realisiert, ich denke das reicht dicke für meine Sicherheitsanforderungen :)
Nun ja, es ist halt semantisch falsch, Werte mit GET an einen Server zu schicken. Außerdem reagieren manche Server allergisch auf zu lange GET-Parameter.
 
Falls du noch Lust hast das rein zu programmieren, würde ich dir den User Agent Check noch empfehlen. :D

Der User Agent ist die Information über den verwendeten Browser, die jeder Client mitschickt. Ist glaube ich nicht so schwer diesen User Agent clientseitig zu ändern:
stackoverflow.com - Setting user agent in Java httpclient and allow redirects to true

Und im PHP Skript prüfst du den User Agent auch nochmal, durch Abfragen von $_SERVER["HTTP_USER_AGENT"]. Damit wird dein Skript nur ausgeführt wenn deine App das anfordert.

Java Beispiel Codeausschnitt: (1. Antwort von stackoverflow Link)
Code:
HttpClient httpclient = new HttpClient();
httpclient.getParams().setParameter(
    HttpMethodParams.USER_AGENT,
    "my android app"
);

PHP Beispiel Codeausschnitt:
PHP:
if ($_SERVER["HTTP_USER_AGENT"] == "my android app")
{
 
    // start script
 
}
 
Dankesehr, werde ich vor dem launch noch umsetzen denke ich!
Hab jetzt mal alles auf Englisch übersetzt... das war ne Arbeit :)

Jetzt noch Privatsphäre und Datentransfer Hinweis, dann kommen wir der Sache schon näher :)
 
Toll, wünsch dir viel Glück dabei! :)

Bin mal deinem Link in der Signatur gefolgt, handelt es sich bei der besprochenen App um das BarcodeGame oder die Mental Math Challenge? ;)
 
Zuletzt bearbeitet:
Nein, das BarcodeGame hab ich als Studienprojekt gemacht.
Es handelt sich um die MathChallenge :)
 
Zurück
Oben