Voutloos schreef op dinsdag 15 mei 2012 @ 21:33:
[...]
Je maakt echter geen enkel valide argument waarom CSRF er af zou moeten. En die ga je ook niet vinden trouwens. En alles eerst langs 1 centraal script leiden is bijvoorbeeld op zichzelf ook niet per se een slecht idee.
CSRF argument:
Het is een var die wordt opgeslagen in de SESSION en die wordt meegestuurd in de POST. Die in de POST moet overeenkomen met die in de SESSION (anders exit). Mijn server accepteert geen cookie's en dus ook geen session_id en dus geen SESSION. Mijn computer wel en daarmee lokaal werkt het script wel (wel elke x uur de CSRF in het script vervangen)
Oftewel: als het kan moet het lokaal en de CSRF ophalen via script kan niet omdat hij dan iets fout doet in de SESSION. (en de oude CSRF blijft)
Langs 1 script is geen slecht idee, maar het is onoverzichtelijk mijns inziens. (ook onhandig voor webadressen, het is nu index.php?view=### voor een pagina)
Manuel schreef op dinsdag 15 mei 2012 @ 21:55:
[...]
Waarom probeer je dan ook het wiel opnieuw uit te vinden? Als het een vast patroon is kan je het toch gewoon met een simpele XPath regel / CSS selector uitlezen? Je maakt nu een probleem wat er helemaal niet is. Er zijn genoeg webscrapers voor PHP beschikbaar, het is alleen een kwestie van zoeken en toepassen. Zelf maak ik gebruik van
Goutte.
Dat gebruik ik al, maar de structuur is zodanig slecht (zonder (duidelijke) classes) dat het dus alsnog 50 (100 incl. ophalen en includen alle bestanden) regels code vergt. (foreach rij, als rij class = header dan die niet en dan foreach cel in die rij en dan foreach cel in die cel-tabel en dan kijken of er de juiste info in staat en dan de links uit die info verwijderen en dan de info in de juiste array zetten met de juiste data)
[...]
En hoe wil je de websiteprogrammeur ervan overtuigen om de CSRF bescherming eruit te halen. Net zoals Voutloos zegt draag je geen enkel argument aan om de bescherming te verwijderen. cURL kan namelijk prima met sessies (cookie) werken zolang je het maar opgeeft. Zie ook de
documentatie van de cURL functie in PHP.
Mijn server niet, nou. In ieder geval gaat er IETS fout... (en de CSRF eruit is makkelijker, want ik moet ook nog tientallen headers en postwaardes en cookies e.d. meegeven)
Als een browser kan inloggen, waarom zou jij dat dan niet kunnen nabootsen? Alle gegevens die je nodig hebt zijn er. De grote uitdaging is om te zien wat het systeem allemaal doet om jouw binnen te laten, als je dat doorhebt zal je script op den duur ook werken.
Dat doe ik dus al, maar die CSRF moet handmatig gaan
Styxxy schreef op dinsdag 15 mei 2012 @ 22:36:
En absoluut niet slecht bedoeld naar
F.West98. Ik begrijp waarom hij zo'n reactie heeft gepost, het is vooral de frustratie dat spreekt (hopelijk toch

). Misschien is het interessant om eens te horen achter een API (of iCal of wat ander formaat er nog bestaat) in plaats van dat je scraping moet toepassen?
Ja, het is best frustrerend om 5 uur te werken aan één weergave en dan enkel een goede array hebben met nog te verwerken info.
De roostersite levert het enkel op deze manier (en geen .ics oid).
En iCal: *kuch* apple *kuch*