GET Parameter in der URL

Guten (Morgen)
Also bisher habe ich immer bei meinem Projekten die Parameter per GET übertragen nur bei dem Browsergame welches ich gerade programmiere sieht das dann doch manchmal nicht schön in der Adresszeile aus.
Beispiel:
xxx.xxx.x.xx/space/index.php?page=game&ac=initwarp&id=2#a
?page=game zeigt die game.inc.php an
&ac=initwarp ist die Aktion die durch einen Link ausgerufen wurde
und &id=2 die zugehörige ID (auf den Link bezogen)
Gibt es da ne Möglichkeit (außer per POST übertragen) das in der Adresszeile einfach immer etwas stehen bleibt und der User diese Parameterübergaben nicht sehen kann.
Ich meine ich könnte natürlich auch für jede kleine Aktion nen machen und dann mit hidden-Fields per POST übertragen aber das ist doch ein riesen Aufwand

Such mal nach "pretty URL". Ruby macht das z.B. automatisch, ich kann Dir aber leider nicht im Detail erklären, wie es funktioniert. Ich tippe mal, das im response header die Url auch noch mal angegeben wird.

Also Daten wie User IDs oder Passwörter etc. solltest du einfach per Session speichern..
Gruß

Wichtige Informationen werden sowieso nicht per GET übertragen, User-ID ist auch in der Session.
Habe mir grad mal diese "suchmaschinenfreundlichen URLs" angeguckt, also mti mod_rewrite. Nur da ich davon kein Plan hab krieg ichs natürlich auch nicht hin
also ich würde gerne zum Test mal
meinserver.de/space/index.php?page=game
=>
meinserver.de/space/game
Kann mir da einer ne RewriteRule schreiben^^

RewriteEngine On
RewriteRule ^(.+)$ index.php?page=$1
Ich würde mir den Aufwand aber sparen. Url-Rewriting benötigt zusätzliche Prozessorzeit und bringt dir in deinem Spiel nichts.
1. Suchmaschinenfreundliche URL brauchst du nicht, da Suchmaschinen den Bereich sowieso nicht indexieren können.
2. Die Daten stehen trotzdem in der URL, nur in einem etwas abgewandelten Format.

Hm und was würdest du als Alternative vorschlagen?

Gibt es da ne Möglichkeit (außer per POST übertragen) das in der Adresszeile einfach immer etwas stehen bleibt und der User diese Parameterübergaben nicht sehen kann.

Also wenn's dir nur darum geht, dass der Benutzer die Parameter nicht sieht, kannst ja einfach nen Frame benutzen, ist dann natürlich die "Lite-Variante", aber als Normalsterblicher steigt man da wohl (meiner Meinung nach) eh nicht dahinter.
Das Problem ist ganz einfach, dass jeder erneute Aufruf des Scripts in einer GET-Anfrage an den Server resultiert, so sieht das nun einmal der HTTP-RFC vor. Du könntest versuchen, einen Container zu bauen, Beispiele dafür sind schlechte AJAX-Seiten, wo nicht das Script aufgerufen wird, sondern immer wieder im Hintergrund per JS die Daten vom Server nachgeladen werden.
Mehr fällt mir dazu im Moment auch nicht ein, sorry...
Mfg AtroX

Hm, wie machen das denn die anderen, Browsergame-Programmierer hier? Übergebt ihr alles per POST oder ist euch das egal wenn in der Adresszeile zich Parameter stehen oder benutzt ihr alle Nen Frame?
Also ich hab's mir mal bei earthlost angeschaut das gefällt mir recht gut mit dem Frame aber ich mag nicht unbedingt.

Die Userdaten hab ich in ner Session, Sachen wie Untermenüs übergeb ich per Get. Deutlich längere Links als "index.php?subID=5" enstehen dabei eigentlich nicht. Hin und wieder mal nen zweiter Parameter, aber mir ist das relativ egal, wie lang die URL wird.

Daten werden ganz normal als GET-Parameter übertragen. Ist mir eigentlich egal ob ein User die sieht oder nicht. Validiert werden müssen sie so oder so. Egal ob ich die via GET, POST oder AJAX-Wrapper übertrage.

Original von Pretandor
Hm, wie machen das denn die anderen, Browsergame-Programmierer hier? Übergebt ihr alles per POST oder ist euch das egal wenn in der Adresszeile zich Parameter stehen oder benutzt ihr alle Nen Frame?
Also ich hab's mir mal bei earthlost angeschaut das gefällt mir recht gut mit dem Frame aber ich mag nicht unbedingt.

Steuerungsdaten sowie ID-Links als GEt, Daten aus Formularen per Post. Es geistert irgendwo ein ein Idiom dafür.. so ähnlich halte ich das immer
Ob der User das sieht oder nicht.. das ist eigentlich egal. Immerhin sind es "lesbare" Urls mit sprechenden Namen, und nicht dieses Ungetüme, wie bei tagesschau, amazon und Co.

Ich persönlich nutze meist ein großes Frameset und darin befindet sich die Seite.
Abgesehen davon: Was ist so schlimm daran, wenn die Spieler die Url sehen?
Ansonsten kannst du die Get-Parameter auch verschlüsseln und mit einem Secret-Key signieren, aber das wäre ein klassischer Overkill.

oder du machst am ende der abrechnung noch nen header('location: meinserver.de/space/index.php?page=game ')

Ich spare mir den ganzen Aufwand per GET noch die aufzurufende Seite mit anzugeben und rufe es direkt auf. Das ist doch Unsinn, da ich Server seitig immer erst überprüfen muss, ob die Seite überhaupt existiert und bla.
Die einzelnen Dateien werden grob nach Aufgaben gegliedert und so müssen nur die nötigsten Sachen angegeben werden. Im Idealfall erkenne ich aus den übergebenen Daten was zu tun, somit entfällt auch ein &action=foobar.

Die Frage mit GET und POST sollte weniger die Frage nach der Optik sein, als mehr nach der Logik dahinter. Aufrufe, welche Daten verändern solltest du niemals per GET vollziehen.

Genau so handhabe ich das auch. Allein schon wegen der F5-geschichte.
show_message.php?message=273
Dagegen ist hingegen nix einzuwenden.

Wichtige Sachen wie schon gesagt immer mit Post.
Ich hab schonmal sowas gesehen: ?delallmsg=true ...kann man prima an andere verschicken und sofort sind alle Nachrichten weg...
Ich persönlich arbeite bei meinem Browsergame mit einem iframe und nur wirklich nötigen Get Daten bzw. wo es nicht wichtig ist ob der User die eventuell sieht (wie Kampfhoernchen geschrieben hat: show_message.php?message=273)

Ich hab bei meinem System mal die Identifikation komplett auf Cookies umgestellt. Das Ergebnis war, das mir mein Lieblingsbugfinder und einziger zweitwichtigster Mitarbeiter einen Link geschickt hat, der mich aus meiner Allianz gehaut hat. Resultat: die Identifikation bei jedem Link ist wieder mit dabei. Funktioniert am sichersten..

Bei der GET/POST Geschichte ist es auch ganz sinnvoll, sich mal in den REST Ansatz einzulesen, selbst wenn man ihn nicht komplett umsetzen will. Aber es wird einem einiges klarer:
HTTP GET => Beziehen von Daten
HTTP POST => Anlegen von Daten
HTTP PUT => Ändern von Daten
HTTP DELETE => Löschen von Daten

Solche Sachen wie index.php?page=game finde ich irgendwie überflüssig, da man doch einfach eine game.php anlegen und diese dann direkt aufrufen kann.
Informationen, die ich von Usern benötige mache ich per POST (Formulardaten), beziehungsweise über SESSION Variablen zur Useridentifikation.
Ich wüsste auch nicht warum man GET benutzen sollte (außer z.B. für ein Forum showtopic.php?topicid=12345).
mfg

Original von Kaiser Nero
Solche Sachen wie index.php?page=game finde ich irgendwie überflüssig, da man doch einfach eine game.php anlegen und diese dann direkt aufrufen kann.

jein.
bei mir liegen in der login.php (über die alles inkludiert wird) alle sachen, die man immer machen muss. schauen, ob der user noch eingeloggt ist, userspezifische berechnungen, die jedes mal zu tun sind, initialisieren der template-engine etc.
ja sicher kann man das auf einzelne datein verteilen, doch das fürt immer zu redundantem code.
ich hatte vorher eine index.php, eine login.php, eine schiffe.php, eine ...
das wird einfach unwartbar.
naja.. aber ich habe eh immer alles etwas anders als die anderen

Deswegen inkludiert mal eine global.php, die all diese Aufgaben erledigt.

genau . und die klinkt sich dann nach bester AOP nochmal automatisch unter den code und räumt alles wieder fein auf ..
@topic:
meinem scripten ist es eh immer wurscht, ob die daten per get oder post kommen. geprüft werden sie ohnehin.. und wenn leute auf links klicken, die andere für sie "preparieren", dann ist das nicht mein problem (zielgruppenabhängig könnte es sich zu einem solchen entwickeln .. aber das prob hab ich nicht).

In totaler Kriegswut ist man durchaus zu solchen Mitteln bereit. Ein einfacher Link im Forum auf einem Thumbnail reicht schon aus.

man muss nichtmal klicken
besondere beschleunigungstechinken rufen den link von selbst auf um die seite in den cache zu legen und dann hat man den salat ohne das man geklickt hat
deshalb kann es auch in die hose gehen wenn man einen ingame link hat "xyz-löschen" oder so.. dafür sollte man dann immer buttons nutzen

Ach wer benutzt schon Prefetching? Dieses Feature nervt doch mehr als es bringt bei normalen Surfverhalten.

Aber man muss leider immer davon ausgehen dass es leute gibt die es nutzen

Solche Leute müssen aber auch damit rechnen, dass in einem Forum gleich alle Threads als gelesen markiert und abonniert werden. Also wirklich sinnvoll ist das nicht, da sich kaum alle an die Richtlinien, wie von Agmemon erwähnt, halten..

GET kann man in einem einfachem Link verwenden und braucht kein Formular oder JS dazu

Unkritische Daten wie z.B. die Topic ID in einen Forum, welche nur Daten zum Anzeigen abrufen und keine verändern, können in der URL per GET übergeben werden. Aber Spielekritische Daten wie Spieler lösche, Gebäude bauen bzw. Abreisen oder dergleichen sollte man immer per POST durchführen. Aber beim Empfangen der Daten, egal ob GET oder POST sollte man sie immer durch eine Richtigkeitsprüfung schicken.