Archief - De koffiepauzehoek

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
d

dJeez

Legacy Member
Dieterg zei:
Ik probeer een REST API te beveiligen, na veel opzoekwerk blijkt dat deze manier de beste approach is?

Ik snap alleen stap 2 niet zo goed, hoe geraak ik aan mijn private key als die niet over het netwerk gestuurd mag worden
Klik om te vergroten...
Ik denk dat volgende video eens moet bekijken : Secure RESTful API Automation with JavaScript - YouTube

TL;DW OAuth2 Implicit grant flow (user-agent flow in de video) is wellicht het antwoord. Je krijgt een (tijdelijke) access token terug bij authenticatie (de authenticatie server kan dan een standaard login/pw validatie doen alvorens die teruggaat naar de redirect url), en geeft die door bij volgende requests (die token kan je dan serverside aan een sessie koppelen en daar ook steeds controleren). Bij uitbreiding kan je dan nog refresh tokens gebruiken (waarmee de client een nieuwe access token kan aanvragen om de sessieduur te verlengen). Client side hashing zou niet echt veel toevoegen (buiten extra overhead), je doet uiteraard wel best alle communicatie over https - zoals de OAuth2 spec het overigens voorschrijft...

Schematisch is het dus dit : https://developers.google.com/accounts/docs/OAuth2#clientside

Een relevante vraag met antwoord op SO : api - How do I implement secure OAuth2 consumption in Javascript? - Stack Overflow.

Nu ja, al het voorgaande is in principe enkel relevant voor publieke APIs, waarbij elke client zijn eigen client_id gebruikt (maw als je de REST API dus als dienst gaat aanbieden aan derden, en elke gebruiker/client een eigen API key krijgt die die dan als client_id gebruikt). Als het geen publieke REST API is kan je hetzelfde principe hanteren maar de access_token ophalen via een standaard user/pw login. Je hebt dan imho wel geen OAuth2 flow nodig.
D

Dieterg

Legacy Member
Bedankt voor de uitleg dJeez. Ik ga het eens op mijn gemak bekijken. Het is in ieder geval geen publieke API, dus ik ga de access_token gewoon ophalen via een standaard user/pw login. Dat lijkt mij nog het eenvoudigste, in de toekomst zal ik dus ook gewoon SSL moeten toevoegen zodat deze token niet leesbaar is over het netwerk.
-

-BVR-

Legacy Member
2,4% van mijn bezoekers gebruiken nog IE8, de rest allemaal IE9 of hoger (14%) en de rest andere browsers. De moeite om IE8 te blijven ondersteunen?
D

De Wouter

Legacy Member
BramVanroy zei:
2,4% van mijn bezoekers gebruiken nog IE8, de rest allemaal IE9 of hoger (14%) en de rest andere browsers. De moeite om IE8 te blijven ondersteunen?
Klik om te vergroten...

Nee. Wie zijn die 2,4%? Mensen zoals mijn schoonmoeder die niet online gaan bestellen omdat ze technologie niet vertrouwen? Mensen die eens rap op hun grootouders hun PC naar je website surfen om iets te checken? Ik persoonlijk trek mij niets meer van IE8 of lager aan, ik maak websites voor de toekomst, eens ze af zijn, eens er wat bezoekers beginnen te komen,... daar tegen is het misschien nog maar 1,9%.

Edit: de middeleeuwen zijn voorbij, get over it. :p
-

-BVR-

Legacy Member
Ik vind IE8 zo een twijfel geval. Lager ondersteun ik ook niet meer. Maar mensen met XP zitten gewoon vast aan IE8... Maar ik denk ook: 't is 2014, dus pech... Blegh!

EDIT: mensen van webdevs.be: nog actief? Heb er nog 'ns (afscheids)postje geplaatst, maar 't is redelijk dood precies.
d

demon326

Legacy Member
BramVanroy zei:
Ik vind IE8 zo een twijfel geval. Lager ondersteun ik ook niet meer. Maar mensen met XP zitten gewoon vast aan IE8... Maar ik denk ook: 't is 2014, dus pech... Blegh!

EDIT: mensen van webdevs.be: nog actief? Heb er nog 'ns (afscheids)postje geplaatst, maar 't is redelijk dood precies.
Klik om te vergroten...


Ik kijk ook regelmatig eens, maar lijkt erop dat Giga totaal geen tijd meer heeft....
C

CrushTheButton

Legacy Member
Ik kijk er ook regelmatig op. En een forum blijft alleen bestaan door de community niet door degene die het heeft opgericht. Giga kan moeilijk elke topic aanmaken.
d

demon326

Legacy Member
CrushTheButton zei:
Ik kijk er ook regelmatig op. En een forum blijft alleen bestaan door de community niet door degene die het heeft opgericht. Giga kan moeilijk elke topic aanmaken.
Klik om te vergroten...

Dat weet ik ook wel, maar uiteindelijk heeft iedereen wel zijn eigen projecten.... Ik had tot voor kort(april) een grote site onder m'n hoede en weinig tijd, nu nog maar een klein forum, maar groeiend en daar steek ik nu m'n tijd in... Webdevs was gewoon een vlucht van 9lives leden, uiteindelijk keerde iedereen terug naar hier :unsure:
d

demon326

Legacy Member
CrushTheButton zei:
Ik kijk er ook regelmatig op. En een forum blijft alleen bestaan door de community niet door degene die het heeft opgericht. Giga kan moeilijk elke topic aanmaken.
Klik om te vergroten...

Dat weet ik ook wel, maar uiteindelijk heeft iedereen wel zijn eigen projecten.... Ik had tot voor kort(april) een grote site onder m'n hoede en weinig tijd, nu nog maar een klein forum, maar groeiend en daar steek ik nu m'n tijd in... Webdevs was gewoon een vlucht van 9lives leden, uiteindelijk keerde iedereen terug naar hier :unsure:
p

profound

Legacy Member
Als uw site er echt erbarmelijk uitziet in IE8, is het grote probleem uw code en niet IE imo. Waarmee ik niemand viseer ofzo eh, voor alle duidelijkheid, het is gewoon maar een opmerking :p
-

-BVR-

Legacy Member
Het gaat om dingen zoals background-size: 100% auto; enzo. Neat stuff, dat je maar moeilijk kan nabootsen op oudere browsers.
D

De Wouter

Legacy Member
Ik vind dat we als web developers / designers af moeten van het gedacht dat je website er op elke browser hetzelfde moet uitzien. Echt hatelijk als mensen afkomen van "Hey, op internet explorer ziet het er wel niet hetzelfde uit." Als je met een fiets naar het werk rijd moet je ook niet verschieten dat het fucking koud is in de winter. Verschillende browsers, verschillende schermpjes en devices dus ook (lichtjes) verschillende uiterlijkheden.
W

W0utR

Legacy Member
De Wouter zei:
Ik vind dat we als web developers / designers af moeten van het gedacht dat je website er op elke browser hetzelfde moet uitzien. Echt hatelijk als mensen afkomen van "Hey, op internet explorer ziet het er wel niet hetzelfde uit." Als je met een fiets naar het werk rijd moet je ook niet verschieten dat het fucking koud is in de winter. Verschillende browsers, verschillende schermpjes en devices dus ook (lichtjes) verschillende uiterlijkheden.
Klik om te vergroten...

Ik vind dat je site er hetzelfde moet uitzien in alle browsers, kleine verschillen zijn begrijpelijk, maar het grootste deel zou toch hetzelfde moeten blijven. Als je wat verstand hebt van HTML & CSS zou je eigenlijk geen al te grote verschillen mogen zien.
D

De Wouter

Legacy Member
Uiteraard geen al te grote verschillen, wat blauw ziet moet niet rood gaan zien he. Ik heb het over die kleine dingen, er zijn mensen die daar moeilijk over doen. Vooral klanten en die moet je overtuigen dat het er niet over perfect hetzelfde moet uitzien.
C

CrushTheButton

Legacy Member
Ik ben zelf nu ook wel iemand die het overal perfect wilt laten uitzien, dus ik snap dan wel de commentaar van de klanten. Als ik zelf iets koop moet het ook in orde zijn. Wel allemaal rekeninghoudend met het feit dat je niet de oudste versies kunt blijven ondersteunen.

Ik hou rekening tot en met IE 8.
-

-BVR-

Legacy Member
CrushTheButton zei:
Ik ben zelf nu ook wel iemand die het overal perfect wilt laten uitzien, dus ik snap dan wel de commentaar van de klanten. Als ik zelf iets koop moet het ook in orde zijn. Wel allemaal rekeninghoudend met het feit dat je niet de oudste versies kunt blijven ondersteunen.

Ik hou rekening tot en met IE 8.
Klik om te vergroten...
Dit.
D

Dieterg

Legacy Member
Hoe zien jullie de toekomst van webdevelopment?

Ik denk echt dat frameworks ala AngularJS de toekomst is. Stiekem hoop ik het ook een beetje, het is zo leuk om er mee te ontwikkelen :-)! Net een website mee gemaakt in combinatie met prerender.io. Website staat nog wel niet online, ik hoop dat het toch iets of wat crawlable gaat zijn door google.
-

-BVR-

Legacy Member
Dieterg zei:
Hoe zien jullie de toekomst van webdevelopment?

Ik denk echt dat frameworks ala AngularJS de toekomst is. Stiekem hoop ik het ook een beetje, het is zo leuk om er mee te ontwikkelen :-)! Net een website mee gemaakt in combinatie met prerender.io. Website staat nog wel niet online, ik hoop dat het toch iets of wat crawlable gaat zijn door google.
Klik om te vergroten...
Ik vrees dat het wat vanalles gaat zijn.

HTML5 doet veel waar vroeger extra mark-up nodig was, of JavaScript - maar heeft ook handige dingen zoals role-attributes. Daarnaast is er altijd CSS3 dat superb is. JS Frameworks zijn fijn, maar ik zie ze niet als noodzakelijk. Ik bedoel: als je nu een website ontwikkelt: welke website ook, dan gebruik je vanzelfsprekend (hopelijk) HTML5 en wat CSS3. Om onmiddellijk een volledig framework te gebruiken is lang niet altijd nodig. Ik hoop daarom dat er verder wordt doorontwikkeld aan CSS en HTML, en dat andere frameworks extra's zijn.
D

Dieterg

Legacy Member
Ik zie het toch wel wat anders :-)..

Om een voorbeeld te geven: Bij mijn vorige projecten begon ik altijd van de back-end naar de front-end te werken. Eerst zorgen dat de database etc in orde was.

Nu met (bv.) AngularJS begin ik aan de front-end, als data maak ik gebruik van JSON-Objecten. Als de front-end klaar is begin ik aan de back-end, bijvoorbeeld een REST Client. Die REST client kan dan gebruik maken van de front-end JSON objecten die ik doorstuur of afhaal. Zo is server side taal en client side taal 100% gescheiden, geen rommelcode meer. Er is orde aan zowel de client als aan de serverkant. Ik zie ook dat ik nu minder lang bezig ben geweest aan dit project én een pak minder code!!

Een REST client heeft dan ook nog eens het voordeel dat er snel een ander soort applicatie aan kan toegevoegd worden zonder dat er iets aan de back-end moet veranderen.

AngularJS voelt imo zeer natuurlijk aan, als ik met jQuery/puur javascript bezig ben heb ik steeds het gevoel dat ik aan het 'hacken' ben.
S

Scissor

Legacy Member
Iemand een goede compressiemethode? Zit met images van 1Mb + die als backstretch dienen. Heb ze al door tinyPng gehaald en in photoshop gesaved voor web maar krijg ze maar niet tot een "redelijk" formaat.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan