Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

[JS] [AJAX] [SSL] Inloggen met AJAX in modal beveiligen

Pagina: 1
Acties:

  • TheNephilim
  • Registratie: september 2005
  • Laatst online: 13-07 11:56
Een project waar ik op dit moment aan werk; een webshop in Wordpress, heb ik een login modal. Deze modal komt in beeld bij het inloggen op de website. Dat inloggen verloopt nu gewoon doormiddel van Ajax en dat werkt prima. Echter worden de gebruikersnaam en wachtwoord gewoon in plain-text verstuurd. Een gewone loginpagina maken en die voorzien van https is een idee, maar misschien zijn er andere oplossingen.

De website maakt gebruik van jQuery en de jQuery.ajax verteld mij:
quote:
Due to browser security restrictions, most "Ajax" requests are subject to the same origin policy; the request can not successfully retrieve data from a different domain, subdomain, or protocol.
Dat zou dus betekenen dat de pagina waarop de Ajax request gedaan word, ook https moet zijn om in de request zelf https te kunnen gebruiken. Op Google kan ik niks vinden waarmee het op te lossen zou zijn, in ieder geval niet op 'standaard' consumenten hosting.

Wat zijn nu goede alternatieven? Zelf gaan encrypten of zijn dat tegenwoordig geen goede oplossingen meer? Of moet ik echt naar een 'dedicated' loginpagina toe waar ik gebruik maak van https?

--- Encrypted AJAX wrapper ---
Een oplossing als deze ziet er bijvoorbeeld wel netjes uit, maar de key... Die kun je niet veilig houden aan de client side.

--- jCryption ---
Een complete library, voor jQuery. Ziet er erg goed uit, maar ik moet nog even uitzoeken wat ik nu aan de serverkant allemaal kan doen.

http://www.jcryption.org/

Een mooie oplossing als je zelf host, maar aangezien proc_open nodig is voor deze oplossing, gaat het niks worden.

Misschien kunnen we om het proc_open probleem heen werken door gebruik te maken van de php functies voor openssl. Op de server waar het project straks live gaat, is openssl aanwezig in php, dus dat moet toch lukken!

TheNephilim wijzigde deze reactie 04-12-2013 11:39 (26%)

VILF Gaming


  • RobIII
  • Registratie: december 2001
  • Laatst online: 20:47

RobIII

Moderator DevschuurŽ

^ Romeinse 3 ja!

quote:
TheNephilim schreef op woensdag 04 december 2013 @ 11:06:
een webshop in Wordpress
[...]
Een gewone loginpagina maken en die voorzien van https is een idee
Dat is geen "idee" maar een must. Een webshop draai je op HTTPS, basta. En daarmee los je meteen heel je topic op. En een SSL certificaat kost tegenwoordig geen drol dus dat is geen excuus (meer).

RobIII wijzigde deze reactie 04-12-2013 11:42 (4%)

Mistakes happen. It's the mistakes inside a For Loop that are a real problem - Scott Hanselman.

Over mij


  • TheNephilim
  • Registratie: september 2005
  • Laatst online: 13-07 11:56
quote:
RobIII schreef op woensdag 04 december 2013 @ 11:41:
[...]


Dat is geen "idee" maar een must. Een webshop draai je op HTTPS, basta. En daarmee los je meteen heel je topic op. En een SSL certificaat kost tegenwoordig geen drol dus dat is geen excuus (meer).
De hele webshop op https? Nou misschien de grote jongens zoals Amazon, maar veel webshops die alleen maar https gebruiken zie ik niet vaak. Bij bol.com bijvoorbeeld, als je daar naar de loginpagina gaat, kom je pas in het https protocol terecht.

VILF Gaming


  • azerty
  • Registratie: maart 2009
  • Laatst online: 22:13

azerty

McFly

quote:
RobIII schreef op woensdag 04 december 2013 @ 11:41:
[...]


Dat is geen "idee" maar een must. Een webshop draai je op HTTPS, basta. En daarmee los je meteen heel je topic op. En een SSL certificaat kost tegenwoordig geen drol dus dat is geen excuus (meer).
StartSSL durft af en toe wel eens problemen geven. Er zijn genoeg andere (Comodo PositiveSSL bijv.) die ook al een enkel domein voor een tientje per jaar (zelfs iets minder) van een certificaat voorzien...

  • jopitan
  • Registratie: juni 2007
  • Laatst online: 14-05 10:10

jopitan

It's just a fact

quote:
RobIII schreef op woensdag 04 december 2013 @ 11:41:
[...]


Dat is geen "idee" maar een must. Een webshop draai je op HTTPS, basta. En daarmee los je meteen heel je topic op. En een SSL certificaat kost tegenwoordig geen drol dus dat is geen excuus (meer).
StartSSL wil wel nog eens als een niet gecertificeerde certificaat op Firefox weergegeven worden. Dat heb ik helaas meerdere keren meegemaakt. Uiteindelijk kost een certificaat nog maar 10 euro per jaar voor een single subdomain certificaat. Alles rewriten in de htaccess naar https://www. en het is klaar.
Daarnaast kosten wildcard certificaten ook geen drol (rond de 70 euro, kan vast nog wel ergens goedkoper worden gevonden)
quote:
TheNephilim schreef op woensdag 04 december 2013 @ 11:47:
[...]


De hele webshop op https? Nou misschien de grote jongens zoals Amazon, maar veel webshops die alleen maar https gebruiken zie ik niet vaak. Bij bol.com bijvoorbeeld, als je daar naar de loginpagina gaat, kom je pas in het https protocol terecht.
Dan zijn die webshops die jij bezoekt allemaal kak. :+ Daarnaast is het naar mijn inziens een schande als je als webshop geen certificaat hebt die ervan verzekerd dat je gegevens niet zomaar door een ander persoon even worden bekeken door een MiTM.
Wie een webshop start en te gierig is om 10 euro te investeren is een webshop niet waard.

jopitan wijzigde deze reactie 04-12-2013 11:58 (31%)

CPU: i7-5820K @ 4.4GHz | CCooler: NZXT Kraken X61 | MEM: Kingston 16GB @ 2666MHz | GPU: RX470 | PSU: OCZ 1250W | SSD: Samsung Pro 500GB


  • TheNephilim
  • Registratie: september 2005
  • Laatst online: 13-07 11:56
quote:
wsitedesign schreef op woensdag 04 december 2013 @ 11:51:
[...]


StartSSL durft af en toe wel eens problemen geven. Er zijn genoeg andere (Comodo PositiveSSL bijv.) die ook al een enkel domein voor een tientje per jaar (zelfs iets minder) van een certificaat voorzien...
Dat is ook geen probleem, de certificaten zijn inderdaad niet duur meer. Zou dat moeten, dan is dan geen probleem.

Ik vraag me alleen af of er geen andere oplossingen zijn die eenzelfde resultaat geven. Als het teveel werk is, of niet veilig genoeg; prima dan gewoon een loginpagina met https evenals natuurlijk de pagina waarop je registreert en accountgegevens bekijkt. Het lijkt me alleen nodig om alle requests, ook het bekijken van producten, helemaal onder https uit te voeren.

VILF Gaming


  • RobIII
  • Registratie: december 2001
  • Laatst online: 20:47

RobIII

Moderator DevschuurŽ

^ Romeinse 3 ja!

quote:
Certificaatje aanvragen + installeren: totaal: 0.5 uur.
Devwerk om allerlei vage constructies te bouwen: veel meer dan 0.5u en dan reken ik het onderhouden van die code door de jaren heen etc. nog niet eens mee.
quote:
Als je zelf gaat knutselen moet je iig. verdomd goed weten wat je aan 't doen bent...
quote:
TheNephilim schreef op woensdag 04 december 2013 @ 11:56:
Het lijkt me alleen nodig om alle requests, ook het bekijken van producten, helemaal onder https uit te voeren.
Wat kost het je als je alles over HTTPS trekt? Tenzij je nu al last hebt van een server die op z'n tenen loopt of als je een enorm serverpark a-la FB, Twitter, Google, BOL.com etc. hebt: boeie. Voor de gemiddelde webshop van de bakker op de hoek is de "extra load" compleet verwaarloosbaar.

RobIII wijzigde deze reactie 04-12-2013 12:00 (8%)

Mistakes happen. It's the mistakes inside a For Loop that are a real problem - Scott Hanselman.

Over mij


  • TheNephilim
  • Registratie: september 2005
  • Laatst online: 13-07 11:56
quote:
RobIII schreef op woensdag 04 december 2013 @ 11:59:
[...]

Certificaatje aanvragen + installeren: totaal: 0.5 uur.
Devwerk om allerlei vage constructies te bouwen: veel meer dan 0.5u en dan reken ik het onderhouden van die code door de jaren heen etc. nog niet eens mee.


[...]

Als je zelf gaat knutselen moet je iig. verdomd goed weten wat je aan 't doen bent...
Dat is ook zo, ik ga eens vragen of de hoster een certificaat kan regelen en hoeveel dat moet kosten. De hosting overigens is verder niet in mijn beheer, dat heeft de klant allemaal.
quote:
[...]

Wat kost het je als je alles over HTTPS trekt? Tenzij je nu al last hebt van een server die op z'n tenen loopt of als je een enorm serverpark a-la FB, Twitter, Google, BOL.com etc. hebt: boeie. Voor de gemiddelde webshop van de bakker op de hoek is de "extra load" compleet verwaarloosbaar.
Ga dat nog even bekijken dan, als het goed is zijn er niet veel aanpassingen nodig. Dus dat zou geen probleem moeten zijn.

VILF Gaming


  • Barryvdh
  • Registratie: juni 2003
  • Laatst online: 19:47
Je moet alleen nog wel vaak een extra IP hebben, wat ook weer extra kosten met zich mee kan brengen.

  • RobIII
  • Registratie: december 2001
  • Laatst online: 20:47

RobIII

Moderator DevschuurŽ

^ Romeinse 3 ja!

quote:
Barryvdh schreef op woensdag 04 december 2013 @ 13:42:
Je moet alleen nog wel vaak een extra IP hebben, wat ook weer extra kosten met zich mee kan brengen.
True; ik heb geen idee wat de prijzen tegenwoordig zijn (we draaien al jaren op eigen bakken in colo) maar laat zo'n IP ≈ ¤ 2,- per maand kosten (gebaseerd de eerste drie hits van een simpele google query)... En een beetje ontwikkelwerk van een junior ¤75,- p/u. Voor de prijs van 1 uur devwerk (en daar ga je geheid (veel) meer overheen) kun je 3 jaar dat extra IP betalen.

RobIII wijzigde deze reactie 04-12-2013 14:57 (4%)

Mistakes happen. It's the mistakes inside a For Loop that are a real problem - Scott Hanselman.

Over mij


  • TheNephilim
  • Registratie: september 2005
  • Laatst online: 13-07 11:56
quote:
RobIII schreef op woensdag 04 december 2013 @ 14:42:
[...]

True; ik heb geen idee wat de prijzen tegenwoordig zijn (we draaien al jaren op eigen bakken in colo) maar laat zo'n IP ≈ ¤ 2,- per maand kosten (gebaseerd de eerste drie hits van een simpele google query)... En een beetje ontwikkelwerk van een junior ¤75,- p/u. Voor de prijs van 1 uur devwerk (en daar ga je geheid (veel) meer overheen) kun je 3 jaar dat extra IP betalen.
Ik heb (via de klant) gevraagd wat de kosten zijn voor zo'n certificaat. Hij komt op 6 euro (excl. btw) per maand, waar ik uitga van de complete oplossing. Er nog maar even een mailtje achteraan gedaan om te vragen welk type certificaat het is, maar dat moet allemaal wel goed komen.

Overigens, ¤ 75,00/u voor een (junior) Wordpress developer lijkt me best veel :9 Maar goed, je hebt wel gelijk; je krijgt het met https allemaal sneller en efficiënter voor elkaar.

De pagina's waarvoor ik in ieder geval https wil gebruiken zijn; inloggen, registreren, mijn account en afrekenen.

VILF Gaming


  • Barryvdh
  • Registratie: juni 2003
  • Laatst online: 19:47
Bij mijn hoster vragen ze 30 euro per jaar voor een extra IP en 42.50 per jaar voor een SSL certificaat (+installatie), dus dat is ongeveer hetzelfde. Ligt er natuurlijk ook aan wat voor certificaat je wil, via https://www.sslcertificaten.nl/ heb je zelf al vanaf 10 euro een certificaat van Comodo, inclusief extra subdomein (www. + zonder ww).

  • RobIII
  • Registratie: december 2001
  • Laatst online: 20:47

RobIII

Moderator DevschuurŽ

^ Romeinse 3 ja!

quote:
TheNephilim schreef op woensdag 04 december 2013 @ 15:06:
De pagina's waarvoor ik in ieder geval https wil gebruiken zijn; inloggen, registreren, mijn account en afrekenen.
Ik zou 't gewoon site-wide doen tenzij je een goede reden hebt om 't niet te doen. Gewoon "blind" alles rewriten van http -> https. Dan heb je over 6 maanden niet opeens iets van "K*T Ooops ik heb die-en-die pagina of die-en-die (uitzonderlijke) combinatie van factoren over het hoofd gezien en dus zijn alle wachtwoorden alsnog al die tijd gewoon doodleuk in clear-text over de lijn gegaan :X ".
quote:
TheNephilim schreef op woensdag 04 december 2013 @ 15:06:
Overigens, ¤ 75,00/u voor een (junior) Wordpress developer lijkt me best veel :9
Laat 't ¤ 50 of ¤ 60 zijn dan. God, weet ik veel waar een junior tegenwoordig voor over de balie gaat... :P :X

RobIII wijzigde deze reactie 04-12-2013 15:46 (28%)

Mistakes happen. It's the mistakes inside a For Loop that are a real problem - Scott Hanselman.

Over mij


  • TheNephilim
  • Registratie: september 2005
  • Laatst online: 13-07 11:56
quote:
Barryvdh schreef op woensdag 04 december 2013 @ 15:43:
Bij mijn hoster vragen ze 30 euro per jaar voor een extra IP en 42.50 per jaar voor een SSL certificaat (+installatie), dus dat is ongeveer hetzelfde. Ligt er natuurlijk ook aan wat voor certificaat je wil, via https://www.sslcertificaten.nl/ heb je zelf al vanaf 10 euro een certificaat van Comodo, inclusief extra subdomein (www. + zonder ww).
Hier krijg ik als optie deze voorgeschoteld: http://www.thawte.nl/nl/producten/ssl123+certificaten/. Dat lijkt me een certificaat zonder groen label.

Op dezelfde website tref ik ook http://www.thawte.nl/nl/producten/web+server+certificaten/ aan, dat is er wel een met groen label als ik me niet vergis.

-- Edit ---

Ik vergis me, http://www.thawte.nl/nl/p...b+server+ev+certificaten/ biedt wel een groen label. De hiervoor genoemde niet.

Nouja, dat laat ik dan verder aan de klant over. Dat groene label is wel mooi en professioneel, maar niet per se nodig.
quote:
RobIII schreef op woensdag 04 december 2013 @ 15:43:
[...]

Ik zou 't gewoon site-wide doen tenzij je een goede reden hebt om 't niet te doen. Gewoon "blind" alles rewriten van http -> https. Dan heb je over 6 maanden niet opeens iets van "K*T Ooops ik heb die-en-die pagina of die-en-die (uitzonderlijke) combinatie van factoren over het hoofd gezien en dus zijn alle wachtwoorden alsnog al die tijd gewoon doodleuk in clear-text over de lijn gegaan :X ".
Duidelijk! Als het https gebeuren eenmaal is opgeleverd ga ik wel eens kijken wat het doet, als ik alles op https zet. Als dat werkt en er geen problemen optreden laat ik het zo, uitzetten en alleen op bepaalde pagina's kan altijd.
quote:
[...]

Laat 't ¤ 50 of ¤ 60 zijn dan. God, weet ik veel waar een junior tegenwoordig voor over de balie gaat... :P :X
Hahaha, nou wij gooien onze websites hier meestal op projectbasis over de schutting, het uurtarief was heel lang ¤ 45, maar dat gaan we vanaf 1 januari 2014 maar eens naar ¤ 50 tillen :+

TheNephilim wijzigde deze reactie 04-12-2013 16:11 (3%)

VILF Gaming


  • RobIII
  • Registratie: december 2001
  • Laatst online: 20:47

RobIII

Moderator DevschuurŽ

^ Romeinse 3 ja!

quote:
TheNephilim schreef op woensdag 04 december 2013 @ 16:07:
Hier krijg ik als optie deze voorgeschoteld: http://www.thawte.nl/nl/producten/ssl123+certificaten/. Dat lijkt me een certificaat zonder groen label.

Op dezelfde website tref ik ook http://www.thawte.nl/nl/producten/web+server+certificaten/ aan, dat is er wel een met groen label als ik me niet vergis.
Ik weet niet wat je met "groen label" bedoelt (ik neem aan dat je 't niet hebt over 't milieu) maar ik ga er van uit dat je EV certificaten (Extended Validation) bedoelt. Voor je probleem ('t versleuteld versturen van je login gegevens) is wel/geen EV niet heel erg spannend en in je code merk je d'r geen fluit van dus dat is, los van de prijs, weinig relevant.
quote:
TheNephilim schreef op woensdag 04 december 2013 @ 16:07:
Nouja, dat laat ik dan verder aan de klant over. Dat groene label is wel mooi en professioneel, maar niet per se nodig.
Juist.
quote:
TheNephilim schreef op woensdag 04 december 2013 @ 16:07:
Duidelijk! Als het https gebeuren eenmaal is opgeleverd ga ik wel eens kijken wat het doet
Je kunt gewoon met een self-signed (-of gratis startssl-) certificaatje ontwikkelen/testen; als je 't maar niet uitrolt naar productie ;)
quote:
TheNephilim schreef op woensdag 04 december 2013 @ 16:07:
Als dat werkt en er geen problemen optreden laat ik het zo, uitzetten en alleen op bepaalde pagina's kan altijd.
Tipje dan nog: The Protocol-relative URL voor je (externe) resources gebruiken (waar mogelijk) ;)
quote:
TheNephilim schreef op woensdag 04 december 2013 @ 16:07:
Hahaha, nou wij gooien onze websites hier meestal op projectbasis over de schutting, het uurtarief was heel lang ¤ 45, maar dat gaan we vanaf 1 januari 2014 maar eens naar ¤ 50 tillen :+
Again: geen idee wat 'n devver tegenwoordig extern kost; ik werk al jaaaaren voornamelijk (lees: 99.5%) intern en dus "niet facturabel". De tijd die ik wél facturabel ben heb ik geen idee wat ze voor me rekenen :P (en don't care either :+ ).

RobIII wijzigde deze reactie 04-12-2013 16:26 (12%)

Mistakes happen. It's the mistakes inside a For Loop that are a real problem - Scott Hanselman.

Over mij


  • TheNephilim
  • Registratie: september 2005
  • Laatst online: 13-07 11:56
quote:
RobIII schreef op woensdag 04 december 2013 @ 16:15:
[...]

Ik weet niet wat je met "groen label" bedoelt (ik neem aan dat je 't niet hebt over 't milieu) maar ik ga er van uit dat je EV certificaten (Extended Validation) bedoelt. Voor je probleem ('t versleuteld versturen van je login gegevens) is wel/geen EV niet heel erg spannend en in je code merk je d'r geen fluit van dus dat is, los van de prijs, weinig relevant.
Met een 'groen label' bedoel ik dit:



Dat is inderdaad een EV certificaat :>
quote:
[...]

Tipje dan nog: The Protocol-relative URL voor je (externe) resources gebruiken (waar mogelijk) ;)
Yup, die gebruik ik al voor de JS libs van Google's CDN, maar handig inderdaad!
quote:
[...]

Again: geen idee wat 'n devver tegenwoordig extern kost; ik werk al jaaaaren voornamelijk (lees: 99.5%) intern en dus "niet facturabel". De tijd die ik wél facturabel ben heb ik geen idee wat ze voor me rekenen :P (en don't care either :+ ).
Haha ja zolang je elke maand een riant bedrag op je bankrekening krijgt bijgeschreven, zou ik me er ook niet druk om maken :+

VILF Gaming


  • RobIII
  • Registratie: december 2001
  • Laatst online: 20:47

RobIII

Moderator DevschuurŽ

^ Romeinse 3 ja!

quote:
TheNephilim schreef op woensdag 04 december 2013 @ 16:43:
Haha ja zolang je elke maand een riant bedrag op je bankrekening krijgt bijgeschreven, zou ik me er ook niet druk om maken :+
Hence de "don't care" O-) :+

RobIII wijzigde deze reactie 04-12-2013 16:47 (5%)

Mistakes happen. It's the mistakes inside a For Loop that are a real problem - Scott Hanselman.

Over mij


  • iH8
  • Registratie: december 2001
  • Laatst online: 25-04 22:47
quote:
TheNephilim schreef op woensdag 04 december 2013 @ 11:06:
Dat zou dus betekenen dat de pagina waarop de Ajax request gedaan word, ook https moet zijn om in de request zelf https te kunnen gebruiken. Op Google kan ik niks vinden waarmee het op te lossen zou zijn, in ieder geval niet op 'standaard' consumenten hosting.
"Pak maar een certificaat" is geen oplossing van de foutmelding die je post maar gewoon een simpele workaround. Je krijgt die melding omdat je content van een ander domein probeert te laden en of je dat nu via HTTP óf HTTPS maakt geen fluit uit. Je probeert een crossdomain request uit te voeren en dat mag nu eenmaal niet van je browser zonder de juiste headers meegeeft en terugkrijgt.

Request-headers:
code:
1
Origin:http://example.org

Response-headers:
code:
1
Access-Control-Allow-Origin:http://www.example.org

Zolang als je controle over je backend hebt en dus de request goed beantwoordt met de juiste headers dan heb je van die bovenstaande melding geen last. Je moet alleen wel opletten met mixed content https://developer.mozilla...ocs/Security/MixedContent maar dat is net zoals certificaten hier momenteel niet on topic.

Je had wat meer op google kunnen vinden als je gezocht had op: crossdomain request, dan was je uitgekomen bij CORS (cross origin resource sharing) http://www.w3.org/TR/cors/

Aunt bunny is coming to get me!


  • RobIII
  • Registratie: december 2001
  • Laatst online: 20:47

RobIII

Moderator DevschuurŽ

^ Romeinse 3 ja!

quote:
iH8 schreef op woensdag 04 december 2013 @ 20:10:
"Pak maar een certificaat" is geen oplossing van de foutmelding die je post
Euh, dat is 't wél:
quote:
TheNephilim schreef op woensdag 04 december 2013 @ 11:06:
Dat inloggen verloopt nu gewoon doormiddel van Ajax en dat werkt prima. Echter worden de gebruikersnaam en wachtwoord gewoon in plain-text verstuurd.
Zoals 'ie het nu heeft werkt 't prima, maar hij wil de gebruikersnaam/wachtwoord niet in plain text versturen.
quote:
iH8 schreef op woensdag 04 december 2013 @ 20:10:
Een gewone loginpagina maken en die voorzien van https is een idee
Die foutmelding krijgt 'ie omdat 'ie de login naar https probeert te versturen vanaf een http pagina:
quote:
Due to browser security restrictions, most "Ajax" requests are subject to the same origin policy; the request can not successfully retrieve data from a different domain, subdomain, or protocol.
quote:
iH8 schreef op woensdag 04 december 2013 @ 20:10:
Dat zou dus betekenen dat de pagina waarop de Ajax request gedaan word, ook https moet zijn om in de request zelf https te kunnen gebruiken.
quote:
Precies de vinger op de zere plek. En de makkelijkste, goedkoopste en beste oplossing is gewoon simpelweg die pagina waarvandaan de Ajax request komt ook vanaf HTTPS serveren. Voila.

Waar jij "content van een ander domein probeert te laden" vandaan haalt zie ik niet :?

RobIII wijzigde deze reactie 04-12-2013 23:05 (6%)

Mistakes happen. It's the mistakes inside a For Loop that are a real problem - Scott Hanselman.

Over mij


  • iH8
  • Registratie: december 2001
  • Laatst online: 25-04 22:47
quote:
Ik kan geen touw aan die quotesessie vastknoppen, ik weet niet wat je probeert te zeggen maar quote me wel goed en anders niet. Ik doe nog wel een poging:

Gaan we weer. Bottomline. Hij was er zelf al achter dat de simpelste oplossing met HTTPS te gaan werken. Daardoor krijgt hij een foutmelding. De oorzaak daarvan is dat de cross origin policy dat blockt. Of hij nu een ander protocol, subdomein of domein aanspreekt mag gewoon niet.

Jullie workaround: complete site op HTTPS zetten. (plus certificaat erbij verkopen)
Echte oplossing: CORS headers goed zetten.

Zo verdienen er jammer genoeg teveel hun geld, ik niet gelukkig. Ik dacht dat er hier gehamerd werd op mensen echt dingen leren en op het goede pad zetten. De eerst volgende keer als die jongen via ajax met een api oid op een ander sub/domein contact maakt krijgt ie dezelfde foutmelding en weet ie nog niets. Alles op HTTPS zetten en certificaatje kopen is het opgelost denkt ie dan. Catching. |:(

Aunt bunny is coming to get me!


  • pedorus
  • Registratie: januari 2008
  • Niet online
Een wachtwoord invullen op een site die deels uit http:// is opgebouwd is veelal te onveilig, dat maakt een man-in-the-middle attack namelijk wel erg eenvoudig... Hoe kun je weten dat er niet een stukje javascript je wachtwoord steelt dan?

Ik heb startssl ergens draaien, en zie geen problemen ermee, ook niet met enige normale versie van Firefox, dus een certificaat kost echt 0 euro, wat een verkopers hier.. :p

  • Hydra
  • Registratie: september 2000
  • Laatst online: 17:27
In HTTP2 worden alle verbindingen versleuteld. Lijkt me dat dat een vrij goeie hint is in wat de juiste oplossingsrichting is.

  • samo
  • Registratie: juni 2003
  • Laatst online: 20:01

samo

Moderator DevschuurŽ

yo/wassup

quote:
RobIII schreef op woensdag 04 december 2013 @ 11:41:
[...]


Dat is geen "idee" maar een must. Een webshop draai je op HTTPS, basta. En daarmee los je meteen heel je topic op. En een SSL certificaat kost tegenwoordig geen drol dus dat is geen excuus (meer).
Ben ik het niet helemaal mee eens. Transacties en persoonsgegevens wil je via SSL aanbieden, maar productaanbod hoeft helemaal niet over SSL.
Oplossing is dus wel inderdaad SSL...

Bekend van cmns.nl | ArneCoomans.nl | Werkt bij True | Het kindertehuis van mijn pa in Ghana


  • RobIII
  • Registratie: december 2001
  • Laatst online: 20:47

RobIII

Moderator DevschuurŽ

^ Romeinse 3 ja!

quote:
samo schreef op donderdag 05 december 2013 @ 09:16:
[...]

Ben ik het niet helemaal mee eens. Transacties en persoonsgegevens wil je via SSL aanbieden, maar productaanbod hoeft helemaal niet over SSL.
Het hoeft niet inderdaad:
quote:
RobIII schreef op woensdag 04 december 2013 @ 15:43:
Ik zou 't gewoon site-wide doen tenzij je een goede reden hebt om 't niet te doen. Gewoon "blind" alles rewriten van http -> https. Dan heb je over 6 maanden niet opeens iets van "K*T Ooops ik heb die-en-die pagina of die-en-die (uitzonderlijke) combinatie van factoren over het hoofd gezien en dus zijn alle wachtwoorden alsnog al die tijd gewoon doodleuk in clear-text over de lijn gegaan :X ".
Gewoon de weg van de minste weerstand, snelste/goedkoopste oplossing; "tenzij je een goede reden hebt om 't niet te doen".
quote:
iH8 schreef op woensdag 04 december 2013 @ 23:44:
Echte oplossing: CORS headers goed zetten.
Dat is geen echte oplossing maar een workaround voor een situatie waarin je je in de nesten werkt met een same origin policy. Als je de pagina serveert van HTTPS en de Ajax request ook over HTTPS stuurt heb je geen drol te maken met een same origin policy en dus geen probleem en geen gedoe met CORS. Makkelijker dan dat kun je 't niet maken. Dat CORS bestaat is allemaal heel leuk enzo maar is hier, in deze situatie, gewoon een lapmiddel voor iets dat helemaal niet gelapt hoeft te worden als je 't goed doet.
quote:
iH8 schreef op woensdag 04 december 2013 @ 23:44:
Zo verdienen er jammer genoeg teveel hun geld, ik niet gelukkig.
:X Schei uit zeg... De laatste keer dat ik wat verdiende aan dit geneuzel... toen waren de mensen nog zwart-wit :X
quote:
iH8 schreef op woensdag 04 december 2013 @ 23:44:
Ik dacht dat er hier gehamerd werd op mensen echt dingen leren en op het goede pad zetten. De eerst volgende keer als die jongen via ajax met een api oid op een ander sub/domein contact maakt krijgt ie dezelfde foutmelding en weet ie nog niets. Alles op HTTPS zetten en certificaatje kopen is het opgelost denkt ie dan. Catching. |:(
Als CORS de oplossing was geweest had ik 't heus wel aangedragen. Maar dat is het niet. Schijnbaar vind jij van wel; prima. Even goeie vrienden. De tijd zal leren wat de beste les is geweest ;)

RobIII wijzigde deze reactie 05-12-2013 11:10 (105%)

Mistakes happen. It's the mistakes inside a For Loop that are a real problem - Scott Hanselman.

Over mij


  • Hydra
  • Registratie: september 2000
  • Laatst online: 17:27
quote:
iH8 schreef op woensdag 04 december 2013 @ 23:44:
Echte oplossing: CORS headers goed zetten.
Welke headers zorgen er dan voor dat een HTTP Origin een HTTPS API mag bevragen dan?
quote:
RobIII schreef op donderdag 05 december 2013 @ 09:35:
Gewoon de weg van de minste weerstand, snelste/goedkoopste oplossing; "tenzij je een goede reden hebt om 't niet te doen".
"Jamaar, NIH!"

Hydra wijzigde deze reactie 05-12-2013 10:08 (36%)


  • Barryvdh
  • Registratie: juni 2003
  • Laatst online: 19:47
quote:
Welke headers zorgen er dan voor dat een HTTP Origin een HTTPS API mag bevragen dan?
Zie dit diagram: http://www.html5rocks.com...cors_server_flowchart.png

Barryvdh wijzigde deze reactie 05-12-2013 10:32 (5%)


  • Hydra
  • Registratie: september 2000
  • Laatst online: 17:27
Dat beantwoord mijn vraag niet. Ik weet prima welke headers er zijn (heb deze week nog een API geimplementeerd), ik vraag welke toestaat dat een HTTP origin een HTTPS api bevraagt.

  • Barryvdh
  • Registratie: juni 2003
  • Laatst online: 19:47
quote:
Hydra schreef op donderdag 05 december 2013 @ 10:21:
Dat beantwoord mijn vraag niet. Ik weet prima welke headers er zijn (heb deze week nog een API geimplementeerd), ik vraag welke toestaat dat een HTTP origin een HTTPS api bevraagt.
Ah sorry.
Maar is dat niet gewoon de Access-Control-Allow-Origin dan? Als je https domein als een unieke 'origin' gezien wordt, moet je het http domein toch toestaan in die header?

  • Hydra
  • Registratie: september 2000
  • Laatst online: 17:27
quote:
Barryvdh schreef op donderdag 05 december 2013 @ 10:25:
Ah sorry.
Maar is dat niet gewoon de Access-Control-Allow-Origin dan? Als je https domein als een unieke 'origin' gezien wordt, moet je het http domein toch toestaan in die header?
quote:
Due to browser security restrictions, most "Ajax" requests are subject to the same origin policy; the request can not successfully retrieve data from a different domain, subdomain, or protocol.
Ik begrijp dus dat dat niet mogelijk is.

  • Barryvdh
  • Registratie: juni 2003
  • Laatst online: 19:47
quote:
Hydra schreef op donderdag 05 december 2013 @ 10:38:
[...]
[...]

Ik begrijp dus dat dat niet mogelijk is.
Ja tenzij je dus CORS correct toepast, zoals iH8 al aangaf.

  • Hydra
  • Registratie: september 2000
  • Laatst online: 17:27
quote:
Barryvdh schreef op donderdag 05 december 2013 @ 10:46:
Ja tenzij je dus CORS correct toepast, zoals iH8 al aangaf.
@@%$@. Ik vraag toch specifiek HOE je dat dan doet?

  • Barryvdh
  • Registratie: juni 2003
  • Laatst online: 19:47
quote:
Hydra schreef op donderdag 05 december 2013 @ 11:16:
[...]
@@%$@. Ik vraag toch specifiek HOE je dat dan doet?
Zoals die flowchart al aangaf, moet je bepaalde headers controleren, valideren of het verzoek is toegestaan en een reactie sturen.
Hier wat meer info: http://docs.webplatform.org/wiki/tutorials/using_cors
Hier een voorbeeld implementatie in php: https://github.com/asm89/stack-cors

Maar een simpele versie is, die in simpele cases voldoende is (of dus ipv * het http domein)
code:
1
header("Access-Control-Allow-Origin: *");


  • Hydra
  • Registratie: september 2000
  • Laatst online: 17:27
Dat snap ik dus prima. Mijn vraag is; staat Access-Control-Allow-Origin: http://hatseflats ook die HTTP URL toe als je een HTTPS url benaderd. Gewoon een Ja / Nee / Ik weet het niet vraag dus.

  • Barryvdh
  • Registratie: juni 2003
  • Laatst online: 19:47
Lijkt me wel dus, aangezien http -> https gezien wordt als crossdomain en dus als een andere origin. Maar dat zei ik ook al in de eerste instantie, en iH8 ook al, dus snap niet waarom je nou zo geďrriteerd raakt.
Ik heb het zelf niet getest, maar probeer het uit zou ik zeggen.

  • iH8
  • Registratie: december 2001
  • Laatst online: 25-04 22:47
Hedendaagse browsers sturen automatisch de juiste access control headers mee op het moment dat je een XMLHttpRequest uitvoert naar een ander protocol, sub of hoofddomein. Met uitzondering van IE natuurlijk, die doen weer apart met een XDomainRequest. Alle frontend frameworks waar ik meegewerkt heb handelen die verschillen keurig voor je af. Je kunt controleren of je juiste headers verstuurt in je browser dev tools. Je hoort dan deze request header te zien:

Request vanaf http://example.org naar https://example.org
code:
1
2
Origin: http://example.org
Host: example.org

Die request moet je beantwoorden je met de juiste access control headers ander krijg je de foutmelding uit de OP. Dat kun je doen op server, host of applicatie niveau. Bijvoorbeeld bij Apache in de virtualhost of htaccess:
code:
1
2
3
<ifModule mod_headers.c>
Header always set Access-Control-Allow-Origin: "http://example.org"
</ifModule>

Of zoals Barryvdh als gaf, op applicatie niveau in PHP:
code:
1
header("Access-Control-Allow-Origin: http://example.org");

Of die header verzonden wordt kun je weer mooi zien in je dev tools bij de response headers

Response van https://example.org naar http://example.org
code:
1
Access-Control-Allow-Origin: http://example.org

Et voila, als de topicstarter nu zijn eerste oplossing jquery en ajax probeert krijgt hij die foutmelding niet meer én heeft ie wat geleerd. Dan gaat hij wel tegen andere dingen aan lopen maar daar had ik het niet over. Natuurlijk voelt een user zich tien keer veilig als ie altijd en overal HTTPS in z'n balk ziet. Is een heel andere discussie en offtopic. En je hoeft geen certificaat te kopen, die kun je keurig zelf signen, again offtopic.Een IP aanschaffen zelfs. Hele discussie gaat overal over behalve over het feit dat de starter zijn foutmelding verkeerd interpreteert, dat wilde ik even corrigeren.

Op grotere projecten ga je steevast tegen dat soort dingen aanlopen. Frontend van mijn huidige project haalt resources van meerdere subdomeinen, vier tileservers, een geojson server, image server etc. Iemand die niet zou weten wat die foutmelding inhield zou zeker aandragen dat alle servers maar naar het hoofddomein verplaatst moeten worden, dan is het ook opgelost. :+

Aunt bunny is coming to get me!


  • Hydra
  • Registratie: september 2000
  • Laatst online: 17:27
@iH8: bedankt.
quote:
Ik vraag simpelweg (nieteens aan jou) of iemand met kennis van zaken aan kan geven of dat ook zo werkt of niet. Aan "lijkt me wel" heb ik dus helemaal niks. Ik kan dat zelf niet 'even' testen want ik heb hier geen projecten die iets dergelijks doen. Als je het niet weet, zeg dat dan gewoon, of reageer gewoon niet. Scheelt ons beiden een hoop tijd.

  • Barryvdh
  • Registratie: juni 2003
  • Laatst online: 19:47
quote:
Hydra schreef op vrijdag 06 december 2013 @ 09:22:
@iH8: bedankt.
[...]
Ik vraag simpelweg (nieteens aan jou) of iemand met kennis van zaken aan kan geven of dat ook zo werkt of niet. Aan "lijkt me wel" heb ik dus helemaal niks. Ik kan dat zelf niet 'even' testen want ik heb hier geen projecten die iets dergelijks doen. Als je het niet weet, zeg dat dan gewoon, of reageer gewoon niet. Scheelt ons beiden een hoop tijd.
Ik bedoel alleen maar dat het volgens de beschrijving/specificatie zo zou moeten werken, aangezien het verschil tussen https/http hetzelfde gezien wordt als tussen 2 totaal verschillende domeinen.
Maar heb het even getest met een ajax get/post tussen (hetzelfde) http en https domein, en zonder die header werkt het niet, maar na toevoegen van de allow-origin header met daarin het http domein, werkt het wel :)

  • Maximized
  • Registratie: april 2004
  • Laatst online: 20:30

Maximized

En niet minimized

quote:
Hydra schreef op vrijdag 06 december 2013 @ 09:22:
Ik vraag simpelweg (nieteens aan jou) of iemand met kennis van zaken aan kan geven of dat ook zo werkt of niet. Aan "lijkt me wel" heb ik dus helemaal niks. Ik kan dat zelf niet 'even' testen want ik heb hier geen projecten die iets dergelijks doen. Als je het niet weet, zeg dat dan gewoon, of reageer gewoon niet. Scheelt ons beiden een hoop tijd.
Ik kan bevestigen wat Barryvdh zegt. Zolang je serverside headers goed staan en je niet IE5.5 gebruikt (:P) moet je gewoon cross-domain via XHR kunnen werken. Let (nogmaals) op de definitie van cross-domain in dit geval; http://mijndomein.org wordt gezien als een ander domein als https://mijndomein.org.

We gebruiken zelf een applicatie die op https://app.domain.com draait, maar XHR doet naar https://backend.domain.com doet, of zelfs naar https://cname.ofthatdomain.com. In firebug zie je netjes dan ook OPTION requests naar de server lopen (een z.g.n. pre-flight request) waarmee wordt gekeken of de request mag worden gedaan.
Een praktijkvoorbeeld kan ik je helaas niet geven daar de applicatie in kwestie nog in ontwikkeling is.. Maar ik kan je wel melden dat het perfect werkt. :)

offtopic:
Kan je verder even normaal doen tegen je mede fora-gebruikers? Iets teveel pepernoten gisteren gegeten waardoor je zo opgeblazen doet tegen anderen? :)


Over de keuze SSL/non-SSL gesproken trouwens: je overhead gaat zitten in HTTP handshakes als je SSL gebruikt, en niet noodzakelijkerwijs in de extra rekenkracht die nodig is om data te versleutelen; die performancehit is niet significant. Mits correct geconfigureerd is er dus niets op tegen om een gehele site op HTTPS te laten draaien, zelfs als er slechts een klein deel (bijvoorbeeld een salesfunnel of een loginpanel) een beveiligde verbinding vereist. Dat geeft het bijkomende voordeel dat de secure-flag van een cookie op true kan worden gezet en deze dus uitsluitend over een versleutelde lijn verstuurd worden en dus niet de ene keer over HTTP en de andere keer over HTTPS.

Maximized wijzigde deze reactie 06-12-2013 19:42 (21%)


  • Hydra
  • Registratie: september 2000
  • Laatst online: 17:27
quote:
Maximized schreef op vrijdag 06 december 2013 @ 19:27:
Een praktijkvoorbeeld kan ik je helaas niet geven daar de applicatie in kwestie nog in ontwikkeling is.. Maar ik kan je wel melden dat het perfect werkt. :)
Goed om te weten. Ben zelf deze week met een API bezig geweest. Die echo's gewoon elke origin request dus die zou dan ook in een dergelijk scenario moeten werken.
quote:
offtopic:
Kan je verder even normaal doen tegen je mede fora-gebruikers? Iets teveel pepernoten gisteren gegeten waardoor je zo opgeblazen doet tegen anderen? :)
Sorry maar ik heb niks aan mensen die op een concrete vraag "ik denk het wel" antwoorden, of eerder, een plaatje dumpen waar niks nieuws in staat. Als ik dan keer op keer moet vragen wat precies bepaalt dat HTTPS-vanaf-HTTP toegestaan is, krijg ik daar geen antwoord op, maar alleen een antwoord op een vraag die ik niet gesteld heb. Reageer dan gewoon niet, scheelt ons beiden tijd :)

  • Maximized
  • Registratie: april 2004
  • Laatst online: 20:30

Maximized

En niet minimized

quote:
Hydra schreef op vrijdag 06 december 2013 @ 19:44:
Goed om te weten. Ben zelf deze week met een API bezig geweest. Die echo's gewoon elke origin request dus die zou dan ook in een dergelijk scenario moeten werken.
Let er wel op dat je vanuit je applicatie niet HTTP-OPTIONS requests volledig gaat afhandelen maar direct stopt met draaien na het echo-en van de CORS-headers. Onze applicatie was eerst ietwat aan te trage kant met cross-domain requests, maar dat bleek dus te liggen aan het feit dat ook preflight requests gezellig door hele hele dispatch stack heen gingen. :P
quote:
Sorry maar ik heb niks aan mensen die op een concrete vraag "ik denk het wel" antwoorden, of eerder, een plaatje dumpen waar niks nieuws in staat. Als ik dan keer op keer moet vragen wat precies bepaalt dat HTTPS-vanaf-HTTP toegestaan is, krijg ik daar geen antwoord op, maar alleen een antwoord op een vraag die ik niet gesteld heb. Reageer dan gewoon niet, scheelt ons beiden tijd :)
Van wat ik zie en lees, bieden verschillende mensen je verschillende informatiebronnen aan met verschillende voorbeelden, specificaties, flowcharts en toelichtingen. Je komt zo _onwijs_ geirriteerd over, terwijl mensen je gewoon proberen te voorzien van informatie. Je zal het vast niet zo bedoelen, maar lees je eigen reacties eens terug. Dat kan allemaal vast wel wat vriendelijker. :)

  • TheNephilim
  • Registratie: september 2005
  • Laatst online: 13-07 11:56
Als het goed is wordt vandaag het certificaat opgeleverd, dus kan ik er eindelijk mee aan de slag. Nog bedankt voor alle reacties hier, het heeft mij weer een mooi inzicht in verschillende oplossingen opgeleverd.

De webshop staat als sinds vrijdag op de productie omgeving. Nog wel achter een .htaccess met wachtwoord, zodat de klant alles nog even kan checken en we de laatste puntjes op de i kunnen zetten.

VILF Gaming


  • TheNephilim
  • Registratie: september 2005
  • Laatst online: 13-07 11:56
De website staat inmiddels online, volledig in https. Wordpress neemt je gedeeltelijk wat werk uit handen en een .htacces lost alle andere losse eindjes op. Hieronder de .htaccess waarvan ik me nog wel even afvraag of dit de juiste volgorde is. Het non-www gedeelte onder het https gedeelte levert problemen op, je krijgt dan de melding dat het certificaat niet geldig is als je de non-www versie in de browser intypt.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

# www
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# https
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Default
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Volgens mij is het nu niet meer mogelijk om de website te bezoeken in http. Je moet https gebruiken en ook alle content word gewoon via https opgehaald. Op deze manier hebben zoekmachines er ook geen moeite meer mee, we moeten namelijk geen duplicate content krijgen en dergelijke.

Tot zover lijkt alles helemaal goed te werken! :D

VILF Gaming


  • R4gnax
  • Registratie: maart 2009
  • Laatst online: 09-07 21:15
quote:
iH8 schreef op donderdag 05 december 2013 @ 15:05:
Hedendaagse browsers sturen automatisch de juiste access control headers mee op het moment dat je een XMLHttpRequest uitvoert naar een ander protocol, sub of hoofddomein. Met uitzondering van IE natuurlijk, die doen weer apart met een XDomainRequest. Alle frontend frameworks waar ik meegewerkt heb handelen die verschillen keurig voor je af. Je kunt controleren of je juiste headers verstuurt in je browser dev tools. Je hoort dan deze request header te zien:
XDomainRequest werkt alleen cross-domain. Niet cross-protocol scheme. Dus je kunt daarmee niet communiceren tussen HTTP en HTTPS. Wat je wel kunt doen is een iframe openen op een HTTPS url, daarmee communiceren via de postMessage API en op die manier het iframe het request naar de server laten doen.

Ondanks dat er dus voor IE8 en 9 een alternatieve oplossing te verzinnen is, is dit nog steeds niet de juiste oplossing. Maakt niet uit door wat voor hoepels of via wat voor trucjes je via HTTP naar HTTPS wilt posten. CORS, XDomainRequest, postMessage iframes; het maakt allemaal geen ene moer uit, want:

VANAF HTTP NAAR HTTPS POSTEN IS NOOIT VEILIG !!!
Het is eerder al gemeld door iemand anders die er gelukkig ook met zijn gedachten bij is, maar daar heb je kennelijk overheen gelezen. Vandaar dus dat ik het hier dik aangezet nog maar eens herhaal.

Als je op een HTTP pagina gegevens invult om via HTTPS versleuteld te versturen dan is dat altijd inherent onveilig. Via een man in the middle aanval op die eerste HTTP pagina kunnen er namelijk al eerder key logging scripts of andere troep toegevoegd zijn en die kunnen dan direct bij de bron, nog voor het wachtwoord versleuteld verstuurd wordt, het al direct oppikken terwijl je het invoert.

  • TheNephilim
  • Registratie: september 2005
  • Laatst online: 13-07 11:56
quote:
R4gnax schreef op woensdag 11 december 2013 @ 20:24:Als je op een HTTP pagina gegevens invult om via HTTPS versleuteld te versturen dan is dat altijd inherent onveilig. Via een man in the middle aanval op die eerste HTTP pagina kunnen er namelijk al eerder key logging scripts of andere troep toegevoegd zijn en die kunnen dan direct bij de bron, nog voor het wachtwoord versleuteld verstuurd wordt, het al direct oppikken terwijl je het invoert.
Niet eens aan gedacht, maar dat is inderdaad meteen een probleem. Dus eigenlijk is inloggen door middel van Ajax nooit een goed idee, tenzij de pagina waarop je dat doet zelf ook https is. Eigenlijk heel logisch natuurlijk, maar daar moet je net even bij stil staan :+

VILF Gaming


  • RobIII
  • Registratie: december 2001
  • Laatst online: 20:47

RobIII

Moderator DevschuurŽ

^ Romeinse 3 ja!

quote:
TheNephilim schreef op donderdag 12 december 2013 @ 10:21:
[...]


Niet eens aan gedacht, maar dat is inderdaad meteen een probleem. Dus eigenlijk is inloggen door middel van Ajax nooit een goed idee, tenzij de pagina waarop je dat doet zelf ook https is. Eigenlijk heel logisch natuurlijk, maar daar moet je net even bij stil staan :+
quote:
RobIII schreef op woensdag 04 december 2013 @ 15:43:
Ik zou 't gewoon site-wide doen tenzij je een goede reden hebt om 't niet te doen. Gewoon "blind" alles rewriten van http -> https. Dan heb je over 6 maanden niet opeens iets van "K*T Ooops ik heb die-en-die pagina of die-en-die (uitzonderlijke) combinatie van factoren over het hoofd gezien en dus zijn alle wachtwoorden alsnog al die tijd gewoon doodleuk in clear-text over de lijn gegaan :X ".

RobIII wijzigde deze reactie 12-12-2013 11:54 (24%)

Mistakes happen. It's the mistakes inside a For Loop that are a real problem - Scott Hanselman.

Over mij


  • TheNephilim
  • Registratie: september 2005
  • Laatst online: 13-07 11:56
quote:
Haha, de webshop is volledig ondergebracht onder het https protocol :Y)

VILF Gaming


  • iH8
  • Registratie: december 2001
  • Laatst online: 25-04 22:47
quote:
R4gnax schreef op woensdag 11 december 2013 @ 20:24:
het maakt allemaal geen ene moer uit, want:

VANAF HTTP NAAR HTTPS POSTEN IS NOOIT VEILIG !!!
Het is eerder al gemeld door iemand anders die er gelukkig ook met zijn gedachten bij is, maar daar heb je kennelijk overheen gelezen. Vandaar dus dat ik het hier dik aangezet nog maar eens herhaal.
quote:
iH8 schreef op donderdag 05 december 2013 @ 15:05:
Et voila, als de topicstarter nu zijn eerste oplossing jquery en ajax probeert krijgt hij die foutmelding niet meer én heeft ie wat geleerd. Dan gaat hij wel tegen andere dingen aan lopen maar daar had ik het niet over
Maar daar heb je kennelijk overheen gelezen. Vandaar dus dat ik het hier dik aangezet nog maar eens herhaal.

:z

Aunt bunny is coming to get me!


  • R4gnax
  • Registratie: maart 2009
  • Laatst online: 09-07 21:15
quote:
iH8 schreef op vrijdag 13 december 2013 @ 14:46:
Maar daar heb je kennelijk overheen gelezen. Vandaar dus dat ik het hier dik aangezet nog maar eens herhaal.

:z
Het onmogelijk maken om direct van HTTP naar HTTPS te posten is juist bedoeld om te zorgen dat mensen niet secure gegevens op insecure pagina's in gaan vullen. Het is dus helemaal niet "een ander probleem". Jij komt gewoon met het foute antwoord aan draven, blijft er een eind over door zagen en moet vervolgens toch nog proberen het laatste woord te halen.

  • iH8
  • Registratie: december 2001
  • Laatst online: 25-04 22:47
Dat jullie willen blijven verkondigen dat het onmogelijk is om HTTPS resources aan te spreken vanaf HTTP moeten jullie helemaal zelf weten. Zegt meer over jullie dan over mij. Ik zeg dat dat wel kan punt. Verder ga ik hier echt niet verder over dimdammen met je. Heel je toon, fontweight, kleurtjes, mijn dialoog af doen met woorden als zagen en doordraven sieren jou, dit topic en GOT echt niet. Fijn weekend!

Aunt bunny is coming to get me!


  • Caelorum
  • Registratie: april 2005
  • Laatst online: 09-07 20:54
Wow, volgens mij spreekt niemand je tegen over dat het kan. Enige dat hier wordt gezegd is dat het niet de (juiste) oplossing is voor dit probleem.
Pagina: 1


Call of Duty: Black Ops 4 HTC U12+ dual sim LG W7 Google Pixel 3 XL OnePlus 6 Battlefield V Samsung Galaxy S9 Dual Sim Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V. © 1998 - 2018 Hosting door True