[safari] Post data komt niet aan

[Roa]

Ik heb onlangs Safari mee geinstalleerd met iTunes om ook m'n site eens in Safari te testen. Hier kwam ik tot de conclusie dat niet al m'n formulieren werken. Na wat uitzoeken blijkt dat m'n forms die ik check met

PHP:

$_SERVER['REQUEST_METHOD'] == 'POST'

wel goed gaan, maar de forms met

PHP:

isset($_POST['login'])

dus niet.

HTML:

<input type="submit" onClick="doLogin(); return true;" value="login" id="login" name="login" class="submit">

Hier komt dus de $_POST['login'] vandaan.

Simpele oplossing: handel al je formulieren af met de werkende controle. Maar dat levert problemen op, omdat m'n login.php eigenlijk op iedere pagina ge-include wordt. Dus ook op de 'password vergeten' pagina, de registratie pagina, enzovoorts. Daarnaast kun je reageren als je eenmaal bent ingelogd, nog meer post data!

Kortom, als ik het met de request_method doe, dan pakt login.php telkens een post actie die niet voor login.php bedoeld is, met als gevolg een error melding, want login.php snapt de binnenkomende data niet. En bijvoorbeeld m'n registratie pagina, heeft input velden die hetzelfde heten als in m'n login form (denk aan username), dus daarop checken gaat ook niet.

In IE en FF werkt het prima, maar Safari geeft dus op de één of andere manier niet de submit mee ofzo.

Is iemand dit al eens tegengekomen en heeft iemand een suggestie om het op te lossen? Het is een kleine site en ondersteuning voor Safari is niet kritiek, maar wel prettig dat ik een oplossing heb voor de toekomst.

[Gersomvg]

Heeft het er niet mee te maken dat je eerst javascript iets laat doen? Dat de submitbutton vervolgens daardoor in Safari niet meer wordt meegepost?

[XWB]

Eens met Gersompie, het probleem zit waarschijnlijk in doLogin().

[Roa]

Behalve dat m'n registratie formulier een soortgelijke functie heeft hangen aan de submit knop, maar die wel prima werkt! Het verschil daartussen is echter de manier hoe ik het server side afhandel. Bij de registratie kijk ik naar de REQUEST_METHOD, bij m'n login naar de $_POST['login'].

Dat was ook het eerste waar ik de problemen in zocht, maar al snel van dat idee afgestapt.

Ik heb momenteel tentamens, dus ben even met wat anders bezig helaas.

[Bosmonster]

Submit-knop-value controle is imho standaard al niet zo'n beste methode, aangezien het gedrag onvoorspelbaar is (dat blijkt maar weer ).

Ik weet wel dat ik dat vrij snel afgeleerd heb lang geleden.

[ Voor 18% gewijzigd door Bosmonster op 07-07-2009 18:01 ]

[Gersomvg]

Ik werk eigenlijk altijd als volgt:

HTML:

<input type="hidden" name="submitted" value="1" />

PHP:

if ($_POST[submitted] == 1)
{

}

[XWB]

Dan krijg je een lekkere warning, netter is om eerst te checken of 'ie wel bestaat. En ook quotes gebruiken, anders probeert php een constante te parsen.

PHP:

if ( isset ( $_POST['submitted'] ) && $_POST['submitted'] == 1 )
{
}

[Spinal]

Waarom iets meesturen waar je verder niks meer mee doet? Je kunt toch veel beter gewoon controleren of alle waarden die je nodig hebt zijn meegestuurd?
In een login-script dus bijv. username en password. Als je controleert of die zijn ingevuld hoef je niet te controleren of je submit-knop is "ingevuld".

[gvanh]

Even iets heel doms ... werkt het wel als je "onClick" schrijft als "onclick"?
In XHTML horen alle attributes toch lowercase te zijn? Ik weet overigens niet of je XHTML gebruikt ... maar het zou niet ondenkbaar zijn.

Dat even los van het feit dat zo'n onclick niet handig werkt ... wat gebeurt er als ik m'n wachtwoord invul en vervolgens op "enter" druk?

[ Voor 13% gewijzigd door gvanh op 07-07-2009 20:12 ]

[Gersomvg]

Hacku schreef op dinsdag 07 juli 2009 @ 18:51:
Dan krijg je een lekkere warning, netter is om eerst te checken of 'ie wel bestaat. En ook quotes gebruiken, anders probeert php een constante te parsen.

PHP:

if ( isset ( $_POST['submitted'] ) && $_POST['submitted'] == 1 )
{
}

Dat laatste kan ik inkomen maar warning? Je kan toch gewoon variabeles aanroepen die niet bestaan?

Om even ontopic te blijven:
Voer het volgende eens in op http://validator.w3.org/#validate_by_input

HTML:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Untitled Document</title>
</head>

<body onClick="">
</body>
</html>

Voila; een error dus Gvanh heeft gelijk

[ Voor 35% gewijzigd door Gersomvg op 07-07-2009 20:32 ]

[XWB]

Dat laatste kan ik inkomen maar warning?

Doe maar eens

PHP:

error_reporting ( E_ALL );

Voila; een error dus Gvanh heeft gelijk

Een validatie-error maar een browser zal dit gewoon uitvoeren.

[ Voor 33% gewijzigd door XWB op 07-07-2009 20:39 ]

[_Thanatos_]

gvanh schreef op dinsdag 07 juli 2009 @ 20:11:
Even iets heel doms ... werkt het wel als je "onClick" schrijft als "onclick"?
In XHTML horen alle attributes toch lowercase te zijn? Ik weet overigens niet of je XHTML gebruikt ... maar het zou niet ondenkbaar zijn.

Ff voor jouw informatie: aan de <input> te zien in de startpost is het geen XHTML, omdat de tag niet wordt gesloten

[tonyisgaaf]

http://got.broes.nl/safariposttest/safariposttest.php
Bij mij registreert Safari gewoon de Submit button? Zal dus wel je JS zijn.

[Bosmonster]

tonyisgaaf schreef op donderdag 09 juli 2009 @ 00:16:
http://got.broes.nl/safariposttest/safariposttest.php
Bij mij registreert Safari gewoon de Submit button? Zal dus wel je JS zijn.

Dat is toch waar dit topic over gaat dacht ik?

Wat je eventueel zou kunnen proberen is ipv

JavaScript:

form.submit();

JavaScript:

form.elements['submitknop'].click();

te doen (pseudo-code).

Als dat het probleem niet is (snap het ff niet meer), waarom handel je het dan niet af via het submit-event ipv de onclick van die button?

[ Voor 14% gewijzigd door Bosmonster op 09-07-2009 01:01 ]

[tonyisgaaf]

Bosmonster schreef op donderdag 09 juli 2009 @ 00:59:
[...]
Dat is toch waar dit topic over gaat dacht ik?

Ik zag alleen nog niemand die expliciet de fout in Safari uitsloot, dus bij deze. Zie het als een extraatje

Wat je eventueel zou kunnen proberen is ipv

JavaScript:

form.submit();

JavaScript:

form.elements['submitknop'].click();

te doen (pseudo-code).

We weten helemaal niet of de TS de form submit in zijn JS, er wordt alleen "true" ge-return-ed op de "onclick", wat volgens mij ook de default waarde is en dus weggelaten kan worden.

Als dat het probleem niet is (snap het ff niet meer), waarom handel je het dan niet af via het submit-event ipv de onclick van die button?

Dat lijkt mij inderdaad ook correcter (onsubmit).

[Roa]

Ik waardeer alles wat jullie posten! Maar ik heb het op het moment even heel druk, dus ik kan even weinig zelf inbrengen, om toch even te tonen dat ik jullie niet vergeten ben

ZanderZ schreef op dinsdag 07 juli 2009 @ 18:53:
Waarom iets meesturen waar je verder niks meer mee doet? Je kunt toch veel beter gewoon controleren of alle waarden die je nodig hebt zijn meegestuurd?
In een login-script dus bijv. username en password. Als je controleert of die zijn ingevuld hoef je niet te controleren of je submit-knop is "ingevuld".

Ja, maar het nadeel daarvan is dat mijn registratie formulier ook username en password heeft.

Wel simpel op te lossen door het login gedeelte andere namen te geven en inderdaad te testen met request_method.

gvanh schreef op dinsdag 07 juli 2009 @ 20:11:
Even iets heel doms ... werkt het wel als je "onClick" schrijft als "onclick"?
In XHTML horen alle attributes toch lowercase te zijn? Ik weet overigens niet of je XHTML gebruikt ... maar het zou niet ondenkbaar zijn.

Dat even los van het feit dat zo'n onclick niet handig werkt ... wat gebeurt er als ik m'n wachtwoord invul en vervolgens op "enter" druk?

Het is HTML, geen XHTML, dus dat is geen probleem. Maar wel een handig puntje opzich.

Enter heeft hetzelfde effect als onclick, hoewel ik me nu inderdaad afvraag waarom dat eigenlijk gebeurd? Ik was altijd gewoon blij dat het werkte

tonyisgaaf schreef op donderdag 09 juli 2009 @ 01:33:
[...]

Ik zag alleen nog niemand die expliciet de fout in Safari uitsloot, dus bij deze. Zie het als een extraatje

Ik had al door dat het aan mij lag, niet aan Safari, maar kennelijk is m'n opzet qua formulieren dus niet helemaal vlekkeloos, waar ik tot nu toe alleen nooit problemen mee gehad heb, omdat ik eigenlijk nooit in Safari getest heb

We weten helemaal niet of de TS de form submit in zijn JS, er wordt alleen "true" ge-return-ed op de "onclick", wat volgens mij ook de default waarde is en dus weggelaten kan worden.

Het formulier wordt inderdaad niet gesubmit via JS, er wordt alleen client-side gecodeerd en een hash gemaakt. Ik zal toch m'n javascript nog even doornemen.

Dat lijkt mij inderdaad ook correcter (onsubmit).

Ja, dat is ook wel een goeie!

Nogmaals, ik heb het nogal druk met andere zaken, maar ik ga zeker dingen doen met jullie suggesties! Kan alleen even duren voor ik update kan posten