Moet altijd alles een moderne SPA zijn?

[Sandor_Clegane]

Lethalis schreef op maandag 23 september 2019 @ 17:03:
[...]

Allemaal zonde van de tijd...

Ach, dat weet ik niet, als je nHibernate had gedaan had je nu grote kans gehad dat je het naar EF moest ombouwen aangezien dat de zegen van MS heeft.

Alles is relatief zeg maar.

Denk dat het punt meer is dat je er niet aan ontkomt, voortschrijdend inzicht zeg maar. Maar belangrijk is ook dat je best kritisch mag blijven. Ik gebruik zelf Unity veel en ook daar kun je hetzelfde punt maken. Neemt niet weg dat doordat je op de "schouders van reuzen" staat je ook ver kan vallen.

Je moet je ook conformeren aan hun visie. Of dat al dan niet de juiste is, moet je voor jezelf uitmaken.

En dat is niet "gratis", goed je hebt er het werk niet van qua programmeren maar je moet je er wel weer in verdiepen en thuis in geraken.

[Lethalis]

Sandor_Clegane schreef op maandag 23 september 2019 @ 18:58:
[...]
Ach, dat weet ik niet, als je nHibernate had gedaan had je nu grote kans gehad dat je het naar EF moest ombouwen aangezien dat de zegen van MS heeft.

Alles is relatief zeg maar.

March 26, 2018
NHibernate 5.1 is released with the support of .NET Core 2.0 and .NET Standard 2.0.

May 8, 2019
EF 6.3 Preview supports .NET Core 3.0

Ik snap jouw punt van voortschrijdend inzicht wel, maar je ziet nu dus dat het in beide gevallen vanzelf goed was gekomen.

Met NHibernate zelfs sneller dan met EF

Maar om terug op het oorspronkelijke topic te komen... het enige dat frontend development zo eng maakt, is de snelheid waarmee alles verandert. Je hoopt gewoon dat als je nu een Angular of React frontend bouwt, dat het nog makkelijk 5 jaar mee kan, het liefst 10 jaar.

Dat kun je een eeuwigheid noemen, maar de meeste projecten waar ik aan werk, gaan makkelijk zolang mee Ik werk nu alweer ruim 12 jaar voor dezelfde werkgever en bijna alles waar ik aan gewerkt heb - op een paar uitzonderingen na - wordt nog steeds dagelijks gebruikt.

En ik haat het om dingen opnieuw te moeten bouwen.

Misschien moet ik dan niet zolang blijven plakken ergens, maar toch

Daarnaast kun je tegenwoordig steeds meer ermee. Dus potentiële Angular / React apps die je nu bouwt, vervangen misschien wel volledig Windows client applicaties met meer dan 100 schermen etc. Dan ben je rustig 2 a 3 jaar aan het bouwen voordat je die app überhaupt in een werkbare staat hebt.

Het zou jammer zijn als al dat harde werk al obsolete is, voordat je het überhaupt opgeleverd hebt.

[ Voor 46% gewijzigd door Lethalis op 23-09-2019 23:08 ]

[GrooV]

Toevallig kom ik dit topic tegen, ben zelf met een project bezig waar iemand alles opgezet heeft in plain Javascript & CSS icm Webpack. Werkt prima en grotendeels goed gedocumenteerd hoe het gebruikt moet worden.

Echter was het feature complete voor de functionaliteit die toen gebouwd moest worden, nu moet er nieuwe functionaliteit aan toegevoegd worden die andere developers dus hier aan toe mogen voegen omdat de persoon die dit bedacht heeft er niet meer werkzaam is.

Dit kost dus extra tijd terwijl als bijvoorbeeld Vue gebruikt was dit er kant en klaar ingezeten had (en ook goed gedocumenteerd voor andere developers). Helemaal als je vaak met wisselende (externe) team samenstelling werkt is het slimmer om dingen van de plank te gebruiken dan een hoop custom op te zetten.

[armageddon_2k1]

@GrooV Maar is dat niet altijd het probleem? Zelfs als Vue gebruikt was dan kost het altijd nog moeite om 'er in te komen' en kost het extra tijd. Dat geldt ook voor als de ontwikkelaar er nog was geweest, maar er een langere tijd tussen had gezeten waarschijnlijk.

[kevintjeb]

Ik wilde dat ook net aanhalen. Ik hoor namelijk van beide kampen een soort van altijd hetzelfde..

'developer X koos voor framework Y. Nu is developer X weg en moeten we framework Y leren. Ik ben beter met Z, dus framework Z had veel sneller geweest'..?

[Matis]

kevintjeb schreef op dinsdag 24 september 2019 @ 08:20:
Ik wilde dat ook net aanhalen. Ik hoor namelijk van beide kampen een soort van altijd hetzelfde..

'developer X koos voor framework Y. Nu is developer X weg en moeten we framework Y leren. Ik ben beter met Z, dus framework Z had veel sneller geweest'..?

Tel daar het not-invented-here syndroom bij op, et voila. Iedere wisseling van de wacht een nieuw framework.

[Sebazzz]

Lethalis schreef op maandag 23 september 2019 @ 22:47:
[...]

Met NHibernate zelfs sneller dan met EF

EF Core 1.0 ondersteunde gewoon .NET Core hoor

[GrooV]

Alleen is het ecosysteem van framework X een stuk groter dan zelfbouw framework Y, denk alleen al aan compatibiliteit, opgeloste bugs, documentatie en vragen op stackoverflow.

En functionaliteit toevoegen aan een framework wat nooit groot gaat worden is in mijn ogen zonde van de tijd. Af gezien al van de tijd die het initieel gekost heeft en die het kost om te blijven onderhouden in de toekomst als Chrome versie XXX ergens een breaking change heeft zitten. Een framework bouw je zelf om een probleem op te lossen, niet omdat je graag zelf iets wil uitvinden

Over 5 jaar is echt nog wel ergens een Vue/Angular/React developer te vinden.

[Lethalis]

Sebazzz schreef op dinsdag 24 september 2019 @ 08:35:
[...]

EF Core 1.0 ondersteunde gewoon .NET Core hoor

Maar EF Core is een complete rewrite van EF die niet feature complete is.

[Hydra]

Matis schreef op dinsdag 24 september 2019 @ 08:21:
Tel daar het not-invented-here syndroom bij op, et voila. Iedere wisseling van de wacht een nieuw framework.

Bij de klant hier moeten we iets bouwen voor een ander team. Daar werd ons verteld dat we gewoon sowieso maar een 'dirty hack' moesten schrijven omdat, wat we ook opleveren, het sowieso weggegooid gaat worden.

Als ZZPer is het natuurlijk prima dat mensen graag enorm veel tijd en geld wegsmijten maar als software engineer zit ik hier regelmatig te facedesken.

[hellum]

Lethalis schreef op maandag 23 september 2019 @ 10:05:
[...]

Ik had er gewoon goed aan gedaan om een standaard library te kiezen (of ik hem nou mooi vind of niet), omdat ik dan "gratis" gebruik maak van het werk dat anderen stoppen in het onderhouden van die library.

Nu heb ik zelf een micro ORM library waarvan ik allang geen zin meer heb om die te onderhouden. Hij zit mij alleen maar in de weg. En dat is ook waar @Hydra op doelt. Dat veel programmeurs allemaal custom libraries bouwen door de jaren heen voor zaken waar dat helemaal niet nodig was geweest.

"hun eigen kleine koninkrijkje van shit"

Ik vond in 2009 dat nhibernate en EF veel te veel overhead gaven en wou iets simpelers. Dapper en veel andere micro ORM's waren er toen nog niet, dus ging ik mijn eigen micro ORM schrijven en door de jaren heen werden ook steeds meer projecten afhankelijk van die library.

Maar je kunt je dus ook afvragen waarom miljoenen programmeurs wél gewoon met nhibernate en EF uit de voeten konden en hun aandacht volledig konden richten op het bouwen van nieuwe functionaliteit voor hun werkgever. En waarom ik per se een eigen micro ORM moest schrijven.

Mijn voorganger heeft hetzelfde gedaan, maar dan nog weer eens gebruikmakend van EF Denk je dat je tegen EF praat, blijkt het uiteindelijk toch een ander framework te zijn.

[Sandor_Clegane]

Lethalis schreef op maandag 23 september 2019 @ 22:47:
[...]

Daarnaast kun je tegenwoordig steeds meer ermee. Dus potentiële Angular / React apps die je nu bouwt, vervangen misschien wel volledig Windows client applicaties met meer dan 100 schermen etc. Dan ben je rustig 2 a 3 jaar aan het bouwen voordat je die app überhaupt in een werkbare staat hebt.

Het zou jammer zijn als al dat harde werk al obsolete is, voordat je het überhaupt opgeleverd hebt.

Wat denk je zelf?

[R4gnax]

GrooV schreef op dinsdag 24 september 2019 @ 08:44:
Alleen is het ecosysteem van framework X een stuk groter dan zelfbouw framework Y, denk alleen al aan compatibiliteit, opgeloste bugs, documentatie en vragen op stackoverflow.

Ik werk zelf met het kleinere en meer onbekende framework CanJS en verkies dat boven bijv. Vue.

Mijn ervaring is dat het niveau van vraag en antwoord voor dit soort frameworks voor 90% niveau "vraagje over PHP anno 1999" is; slecht en vaak fout. Je hebt er veel meer aan als je bijv regelrecht in een chat met de developers van het framework kunt stappen.
De metriek opgeloste bugs zegt ook niet veel over bugs die mogelijk nog in een product schuilen. Het enige wat 'veel bugs opgelost' zegt, is dat er veel zichtbaar gevonden zijn, wat eerder een negatief iets is en terug vertaalt naar een tekortkoming op het gebied van tests en secuurheid bij de ontwikkelaar.

Veel belangrijker is de snelheid waarmee een gerapporteerde bug opgepakt kan worden, en met hoeveel gemak er bijv. naar tussentijdse korte-termijn oplossingen gezocht kan worden. Tot dusver heb ik bij Vue 2 bugs gerapporteerd incl. reproductie stappen waar beiden 2 maanden lang niet eens op gereageerd is. De eerste is zonder boe-of-bah geautomatiseerd gesloten; de 2e werd met de hand gesloten met de claim dat het opgelost was in een nieuwere versie. Was niet het geval, dus een nieuwe bug geopend. 4 maanden of zo geen antwoord op gehad; dan maar direct één van de ontwikkelaar een at-je gedaan en nagevraagd waarom het zo moeilijk was om zelfs maar even antwoord te krijgen. Nu, alweer ongeveer 6 maanden later nog steeds geen antwoord.

Ondertussen heb ik drie bugs bij CanJS gerapporteerd met repro case; binnen een dag antwoord van één van de hoofdontwikkelaars; discussie over gehad; in één geval op de dag zelf nog een patch uitgerold gekregen en in een ander geval binnen een week of zo. (Iets complexere issue; vereiste ook uitrol van meerdere upgrades voor sub-packages.) Alleen de 3e staat nog open. Eigen schuld; mijn repro-case zat een bug in, waar ik pas veel later achter kwam.


Alles heeft z'n ups en z'n downs. Maar als ik hier zou moeten kiezen, kies ik toch niet voor de grotere frameworks met logge processen en turn-overs. Eerder voor de kleinere met een gedreven team er achter, wat down-to-earth mee denkt.

[GrooV]

R4gnax schreef op dinsdag 24 september 2019 @ 22:17:
[...]


Ik werk zelf met het kleinere en meer onbekende framework CanJS en verkies dat boven bijv. Vue.

Mijn ervaring is dat het niveau van vraag en antwoord voor dit soort frameworks voor 90% niveau "vraagje over PHP anno 1999" is; slecht en vaak fout. Je hebt er veel meer aan als je bijv regelrecht in een chat met de developers van het framework kunt stappen.
De metriek opgeloste bugs zegt ook niet veel over bugs die mogelijk nog in een product schuilen. Het enige wat 'veel bugs opgelost' zegt, is dat er veel zichtbaar gevonden zijn, wat eerder een negatief iets is en terug vertaalt naar een tekortkoming op het gebied van tests en secuurheid bij de ontwikkelaar.

Veel belangrijker is de snelheid waarmee een gerapporteerde bug opgepakt kan worden, en met hoeveel gemak er bijv. naar tussentijdse korte-termijn oplossingen gezocht kan worden. Tot dusver heb ik bij Vue 2 bugs gerapporteerd incl. reproductie stappen waar beiden 2 maanden lang niet eens op gereageerd is. De eerste is zonder boe-of-bah geautomatiseerd gesloten; de 2e werd met de hand gesloten met de claim dat het opgelost was in een nieuwere versie. Was niet het geval, dus een nieuwe bug geopend. 4 maanden of zo geen antwoord op gehad; dan maar direct één van de ontwikkelaar een at-je gedaan en nagevraagd waarom het zo moeilijk was om zelfs maar even antwoord te krijgen. Nu, alweer ongeveer 6 maanden later nog steeds geen antwoord.

Ondertussen heb ik drie bugs bij CanJS gerapporteerd met repro case; binnen een dag antwoord van één van de hoofdontwikkelaars; discussie over gehad; in één geval op de dag zelf nog een patch uitgerold gekregen en in een ander geval binnen een week of zo. (Iets complexere issue; vereiste ook uitrol van meerdere upgrades voor sub-packages.) Alleen de 3e staat nog open. Eigen schuld; mijn repro-case zat een bug in, waar ik pas veel later achter kwam.


Alles heeft z'n ups en z'n downs. Maar als ik hier zou moeten kiezen, kies ik toch niet voor de grotere frameworks met logge processen en turn-overs. Eerder voor de kleinere met een gedreven team er achter, wat down-to-earth mee denkt.

Ik heb dan weer een totaal andere ervaring met een Vue JS datepicker die ik toevallig precies had wat ik nodig had, in 1 dag opgelost. Scheelt ook als je het volledig reproduceerbaar maakt met een JSFiddle

Uiteraard kan je bij een opensource project geen support op bugs claimen, en gaat alles best effort. Het mooie er van is dat je zelf natuurlijk ook iets kan bijdragen mocht het echt blokkerend zijn. Developers doen echt wel hun best maar hebben ook maar 40 uur in een week zitten.

Kijk voor de gein maar eens hoeveel bugs er open staan bij de .NET projecten van Microsoft op Github

[Accretion]

Tegenwoordig heb je toch "web components", react en angular zijn alweer uit de tijd.

Achja, het is ook 'n beetje "whatever floats your boat", maar het is inderdaad zo dat het internet vol staat met half-gebakken blogjes die eigenlijk allemaal hetzelfde is omdat iedereen voor zijn 'portfolio' exact hetzelfde idee kopieert van een ander blog.

[GrooV]

Accretion schreef op woensdag 25 september 2019 @ 00:21:
Tegenwoordig heb je toch "web components", react en angular zijn alweer uit de tijd.

Achja, het is ook 'n beetje "whatever floats your boat", maar het is inderdaad zo dat het internet vol staat met half-gebakken blogjes die eigenlijk allemaal hetzelfde is omdat iedereen voor zijn 'portfolio' exact hetzelfde idee kopieert van een ander blog.

"Tegenwoordig" en "Uit de tijd"

React en webcomponents lossen andere problemen op en kunnen elkaar gewoon aanvullen ( https://reactjs.org/docs/web-components.html ). Volgens mij gaat het hiet ook mis bij dit soort "meningen".

Webcomponents zijn ook nog niet af, voor templating moet je kiezen tussen 5 verchillende lib's omdat de spec nog in draft is. Server side rendering is alleen mogelijk op een hacky manier. Voor state heb je nog steeds iets als Redux nodig, voor routing zal je ook een router mogen kiezen.

Verder ondersteund Apple niet alle features van Webcomponents ( https://github.com/w3c/we...09#issuecomment-230700060 ) en om nog maar te zwijgen over IE11 support.

Dus als je een state, SSR, compatibiliteit of wat andere spannendere features wil zit je nog steeds vast aan tig frontend libraries.

Dat WC's zeker toekomst hebben zal niemand ontkennen maar om te zeggen dat frameworks geen toekomst hebben is te kort door de bocht. Er is namelijk niks mis met een goed framework, je moet namelijk niet altijd een framework gebruiken net zoals je niet altijd geen framework moet gebruiken.

Pick the right tool for the job

[Sandor_Clegane]

GrooV schreef op woensdag 25 september 2019 @ 08:35:
[...]


Pick the right tool for the job

En anders wacht je even en dan is er weer een nieuw Frameworkje du jour for the job.

[Lethalis]

GrooV schreef op woensdag 25 september 2019 @ 08:35:
[...]
Om nog maar te zwijgen over IE11 support.

Enigszins uit context, maar veel moderne JavaScript libraries vermelden IE11 niet eens meer als ondersteunde browser op hun github pagina's. Ergens ook wel terecht. Het is gewoon jammer dat er nog zoveel mensen zijn in het bedrijfsleven die het per se willen gebruiken.

Al was ik wel blij toen het uitkwam voor Windows Server 2012 recentelijk, omdat we nog klanten hadden die op IE10 vastzaten

Sandor_Clegane schreef op dinsdag 24 september 2019 @ 17:24:
[...]
Wat denk je zelf?

Ik ben er als de dood voor, eerlijk gezegd

Aan de ene kant ben ik een voorvechter van webapplicaties en zie ik het als de enige toekomstbestendige oplossing, aan de andere kant is web development een soort Vietnam geworden waarbij elke stap die je zet, de verkeerde kan zijn.

Hoe langer de doorlooptijd van het beoogde project, hoe enger het wordt.

Accretion schreef op woensdag 25 september 2019 @ 00:21:
Het is inderdaad zo dat het internet vol staat met half-gebakken blogjes die eigenlijk allemaal hetzelfde is omdat iedereen voor zijn 'portfolio' exact hetzelfde idee kopieert van een ander blog.

Ja irritant is dat.

Soms zoek ik naar diepgaandere informatie over iets, en dan krijg ik op 20 verschillende blogs hetzelfde Hello World voorbeeld van 1 of andere hipster met een baard en zijn MacBook

I'm getting too old for this shit. En ik ben pas 38.

Ik hou ook mijn hart vast voor als ik ooit weer moet solliciteren... al die bedrijven die hip proberen te zijn. En dan zie je een foto van een kantoor met een knalrode muur (waar ik agressief van word) met 1 of andere slogan er op en het jaarlijkse Ski uitje met de zaak

Dingen waar ik echt 0,0 om geef. Maar goed, dat even terzijde

Mijn online "aanwezigheid" is ook minimaal. Ik ben gestopt met Facebook en dergelijke. Geen zin om een cover life te fabriceren om "interessant" te lijken en mezelf af te trekken op de likes die ik krijg.

[ Voor 78% gewijzigd door Lethalis op 25-09-2019 22:03 ]

[Grijze Vos]

Lethalis schreef op dinsdag 24 september 2019 @ 09:01:
[...]

Maar EF Core is een complete rewrite van EF die niet feature complete is.

En godsgruwelijk traag feature complete wordt gemaakt.
Elk jaar een major release he. Als jouw broodnodige feature er nu niet in zit, heb je hem -misschien- volgend jaar wel. Maar ik zie ook features die al sinds 2015 op de roadmap staan er nog niet in zitten. Ach, gelukkig hebben ze spatial datatypes toegevoegd recent, dat is iets wat elke developer dagdagelijks gebruikt natuurlijk. Views fatsoenlijk ondersteunen heb je toch niet nodig. ><

Suffice to say dat ik op het werk geregeld heb dat we gaan overstappen op LLBLGen. De API is misschien wat minder strak dan die van EF, de perf is beter. En het is geschift dat EfBe (in zijn eentje / met een klein team?) meer werk weet te verzetten dan complete afdelingen bij MS.

[Lethalis]

Grijze Vos schreef op woensdag 25 september 2019 @ 22:15:
[...]
Suffice to say dat ik op het werk geregeld heb dat we gaan overstappen op LLBLGen. De API is misschien wat minder strak dan die van EF, de perf is beter. En het is geschift dat EfBe (in zijn eentje / met een klein team?) meer werk weet te verzetten dan complete afdelingen bij MS.

Het verbaast me niet eerlijk gezegd.

Ik volg het hele .NET Core traject al een tijdje sinds versie 1.0. Volgens mij vergaderen ze daar meer dan ze programmeren en dan krijgen ze het nog voor elkaar om rare beslissingen te nemen over zo ongeveer alles.

Heb meerdere keren van die momenten gehad dat ik het niet meer zag zitten en erover nadacht om maar iets anders te leren dan de Microsoft stack.

Inmiddels gaat het wel weer... maar pfff.

Ik heb overigens op diverse blogs EfBe zijn rants regelmatig voorbij zien komen over .NET Core

[ Voor 18% gewijzigd door Lethalis op 25-09-2019 23:42 ]

[Sandor_Clegane]

Lethalis schreef op woensdag 25 september 2019 @ 23:27:
[...]

Het verbaast me niet eerlijk gezegd.

Ik volg het hele .NET Core traject al een tijdje sinds versie 1.0. Volgens mij vergaderen ze daar meer dan ze programmeren en dan krijgen ze het nog voor elkaar om rare beslissingen te nemen over zo ongeveer alles.

Heb meerdere keren van die momenten gehad dat ik het niet meer zag zitten en erover nadacht om maar iets anders te leren dan de Microsoft stack.

Inmiddels gaat het wel weer... maar pfff.

Ik heb overigens op de .NET developer blogs EfBe zijn rants regelmatig voorbij zien komen

Hahaha, dat heb ik nu ook. Ik heb echt het idee dat het in hun DNA zit om defeat uit de jaws of victory te snatchen.

HTTPlistener is ook zo'n mooi voorbeeld.... "Neem maar kestrel"

Het is ook de reden dat ik niet de HTTP client gebruik. Ja het is ruk, maar ik maak liever zelf mijn requests dan dat een exception in een gedeelde client alle uitstaande async awaits opdoekt omdat het onderliggende object ergens een exception heeft gehad.

Maar ja, dat F#......

[Grijze Vos]

Lethalis schreef op woensdag 25 september 2019 @ 23:27:
[...]

Het verbaast me niet eerlijk gezegd.

Ik volg het hele .NET Core traject al een tijdje sinds versie 1.0. Volgens mij vergaderen ze daar meer dan ze programmeren en dan krijgen ze het nog voor elkaar om rare beslissingen te nemen over zo ongeveer alles.

Heb meerdere keren van die momenten gehad dat ik het niet meer zag zitten en erover nadacht om maar iets anders te leren dan de Microsoft stack.

Herkenbaar.

Hetzelfde nu met de GRPC support in .NET Core. Ze stoppen superveel effort in het ondersteunen van het ding in ASP .NET Core. Ze implementeren de helft van de features.

Dan stoppen ze wel veel effort in het stroomlijnen van het ASP.NET Core gedeelte (waarom niet gewoon op .NET Core laten werken, waarom moet die ASP stack erin gevouwen worden? Ik wil GRPC niet hosten in IIS, waarom zou ik.)

En de andere helft van de effort zit in het native in CLR ondersteunen van grpc, ipv de onderliggende C lib te gebruiken. Die redenatie kan ik nog een beetje volgen, maar ook dat gaat op termijn weer subtiele implementatieverschillen veroorzaken, weet ik nu al.

Kijk, gelukkig draaien wij single stack (.NET), dus maakt het mij niet zoveel uit. Maar je zult maar multi-stack zijn en rare subtiele bugs krijgen in je infrastructuur libraries.

[ Voor 24% gewijzigd door Grijze Vos op 26-09-2019 14:08 ]

[Hydra]

Grijze Vos schreef op donderdag 26 september 2019 @ 14:08:
Hetzelfde nu met de GRPC support in .NET Core. Ze stoppen superveel effort in het ondersteunen van het ding in ASP .NET Core. Ze implementeren de helft van de features.

Dat ze na al die tijd nog niet geleerd hebben dat dat een fucking slecht idee is zeg...

Dat soort 'hype' shit moet je gewoon lekker aan libraries overlaten. Heck; Java heeft sinds kort een 'modernere' Http Client en niemand geeft ene shit omdat iedereen al lang een van de vele Http Client libraries gebruikt. Het supporten van een specifiek serialisatie smaakje of whatever moet je niet in je std lib hebben. In Java heb je nu ook een hoop shit omdat ze in nieuwere versies een hoop XML meuk uit de core libraries hebben moeten slopen. Da's een van de redenen dat Java 8 zo lang op zich liet wachten.

[Sandor_Clegane]

Wat me het meest irriteert zijn de complete rewrites van stukken software waardoor je na 3 jaar nog niet eens zover bent als je 3 jaar geleden al was. Ja ik snap dat keuzes uit het verleden nu misschien beter kunnen maar het is gewoon steeds hetzelfde geneuzel.

Het hele .Net core had ook wel anders aangepakt kunnen worden.

[Lethalis]

Grijze Vos schreef op woensdag 25 september 2019 @ 22:15:
[...]

En godsgruwelijk traag feature complete wordt gemaakt.
Elk jaar een major release he. Als jouw broodnodige feature er nu niet in zit, heb je hem -misschien- volgend jaar wel. Maar ik zie ook features die al sinds 2015 op de roadmap staan er nog niet in zitten. Ach, gelukkig hebben ze spatial datatypes toegevoegd recent, dat is iets wat elke developer dagdagelijks gebruikt natuurlijk. Views fatsoenlijk ondersteunen heb je toch niet nodig. ><

Suffice to say dat ik op het werk geregeld heb dat we gaan overstappen op LLBLGen. De API is misschien wat minder strak dan die van EF, de perf is beter. En het is geschift dat EfBe (in zijn eentje / met een klein team?) meer werk weet te verzetten dan complete afdelingen bij MS.

Weet je wat ik eigenlijk nog vervelender vind? Dat ze bij zo ongeveer alles ervan uitgaan dat je EF gebruikt. Zo ook met ASP.NET Identity en IdentityServer4.

Ik moet een goede authenticatie en autorisatie flow bouwen voor een SPA en ik heb geen zin het wiel opnieuw uit te vinden.

Dus neig ik gewoon naar het gebruiken van IdentityServer4 met OAuth2 en PKCE. Maar ik wil geen EF rommel erbij

Als ik dan weer zie wat voor een gedoe dit allemaal is om het zonder EF te doen pfff.

Natuurlijk kan ik ook de boel omzeilen door zelf JWT tokens te genereren, maar dan krijg je dus met allerlei security concerns te maken waarvan het juist fijn is als die door een standaard library worden afgevangen.

Want zelf JWT access tokens maken, komt in grote lijnen met een Implicit Grant flow overeen met ditto security concerns. Refresh tokens mogen dan eigenlijk zelfs niet eens



/einde rant

Tot zover "even snel" authenticatie integreren in mijn SPA. Ik begin mijn cookies te missen (die overigens nog wel vaak worden gebruikt icm tokens zie ik op diverse blogs, dan wel met HttpOnly, secure etc).

Als iemand nog tips heeft, zijn ze welkom

Time is not on my side...

Hydra schreef op donderdag 26 september 2019 @ 14:23:
[...]
Dat ze na al die tijd nog niet geleerd hebben dat dat een fucking slecht idee is zeg...

Sterker nog, ze zijn een eigen JSON library aan het bouwen, terwijl iedereen gewoon NewtonSoft gebruikt.

Allemaal voor een klein beetje extra performance... maar weet God hoeveel compatibiliteit issues dit weer gaat opleveren.

[ Voor 11% gewijzigd door Lethalis op 29-09-2019 11:50 ]

[Sandor_Clegane]

En in plaats van dat ze die dude van NewtonSoft nu wat centen doen moeten ze het zelf weer schrijven. EF vs nHibernate was net zo'n verhaal.

[defiant]

Het commerciële punt van Microsoft is dan ook dat het .NET framework voor de belangrijkste componenten een officieel ondersteunde Microsoft variant beschikbaar heeft. D.w.z. in tegenstelling tot Java, hoef je als je wilt geen keuzes te maken, maar kies je voor EF, WCF (niet in core), ASP.NET MVC, etc.

Het probleem is alleen dat niet alle componenten Microsoft even volwassen waren of een langdurig leven waren beschoren. Vanuit de ORM wereld is er altijd veel kritiek geweest op EF, zeker in het begin. Met de komst van .NET Core slaat Microsoft weer een nieuwe richting in waarin er bijvoorbeeld opeens een officieel Microsoft DI framework aanwezig is, maar aan de andere kant afscheid wordt genomen van een officieel component voor SOAP services (wat in de corporate/enterprise wereld nog veel wordt gebruikt).

Het lijkt erop alsof MS wil meeliften op de snel bewegende wereld van web/cloud/etc.

[Grijze Vos]

Lethalis schreef op zondag 29 september 2019 @ 11:37:
[...]

Tot zover "even snel" authenticatie integreren in mijn SPA. Ik begin mijn cookies te missen (die overigens nog wel vaak worden gebruikt icm tokens zie ik op diverse blogs, dan wel met HttpOnly, secure etc).

Als iemand nog tips heeft, zijn ze welkom

Time is not on my side...

Wij generaten idd zelf JWT tokens en stoppen die in een cookie. Moet eerlijk zeggen dat ik het niet gebouwd heb en er vrij weinig van weet. Heb alleen de implementatie as is netjes weggewerkt in onze nieuwe .NET Core architectuur nadat mijn collega het gebouwd had.

Wij moesten wel integreren met onze oude zooi, dus we zetten sowieso twee cookies op het moment, voor beiden implementaties.

Sandor_Clegane schreef op zondag 29 september 2019 @ 13:16:
En in plaats van dat ze die dude van NewtonSoft nu wat centen doen moeten ze het zelf weer schrijven. EF vs nHibernate was net zo'n verhaal.

Dat doen ze al, die dude werkt voor MS. Vaag dat ze het opnieuw bouwen. Verbeter dan gewoon Newtonsoft.Json, desnoods breng je het onder in een MS namespace.

[ Voor 20% gewijzigd door Grijze Vos op 29-09-2019 20:17 ]

[Lethalis]

defiant schreef op zondag 29 september 2019 @ 14:00:
Het commerciële punt van Microsoft is dan ook dat het .NET framework voor de belangrijkste componenten een officieel ondersteunde Microsoft variant beschikbaar heeft. D.w.z. in tegenstelling tot Java, hoef je als je wilt geen keuzes te maken, maar kies je voor EF, WCF (niet in core), ASP.NET MVC, etc.

Daar voldoen ze al een tijdje niet meer aan.

Sterker nog, open source is een manier voor ze om juist steeds meer dingen af te stoten. Daarom verbaast het mij ook dat ze soms alsnog weer iets zelf gaan doen, zoals die JSON library.

Een groot bedrijf als Microsoft denkt simpelweg door de community bij een project te betrekken, dat ze dan met minder mensen in dienst bepaalde producten in leven kunnen houden. Als je op github kijkt wie er dan commit, dan is het ook nog eens vaak een intern.

Vanuit de ORM wereld is er altijd veel kritiek geweest op EF, zeker in het begin. Met de komst van .NET Core slaat Microsoft weer een nieuwe richting in waarin er bijvoorbeeld opeens een officieel Microsoft DI framework aanwezig is, maar aan de andere kant afscheid wordt genomen van een officieel component voor SOAP services (wat in de corporate/enterprise wereld nog veel wordt gebruikt).

Het lijkt erop alsof MS wil meeliften op de snel bewegende wereld van web/cloud/etc.

Ook al wil je graag een eigen ORM oplossing aanbieden, dan nog is het handig als je klanten / gebruikers de mogelijkheid geeft om er aan te knopen wat je maar wil.

Nu kan dat met IdentityServer ook, maar Microsoft documenteert dat scenario niet / nauwelijks. Alle voorbeelden gebruiken EF. Dus als jij geen EF maar NHibernate of Dapper wil gebruiken, dan moet je het van de community hebben en eindig je al snel op iemand zijn blog die dan een artikel schrijft met een enorm stappenplan dat je denkt van "really? voor zoiets simpels?".

Microsoft duwt EF door je strot met zo ongeveer alles dat je wil doen. Sowieso is een nieuw ASP.NET Core project maken een mijnenveld. Ik kies altijd voor een Empty Project template, en voeg dan elk dingetje dat ik wil handmatig toe... anders krijg ik er een berg zooi bij waar ik helemaal niet op zit te wachten. Van uitgebreide telemetrie, EF, tot en met allemaal JavaScript en bootstrap libraries waarvan ik helemaal niet wil dat Visual Studio die beheert.

Ach ja.

Grijze Vos schreef op zondag 29 september 2019 @ 20:16:
[...]
Wij generaten idd zelf JWT tokens en stoppen die in een cookie. Moet eerlijk zeggen dat ik het niet gebouwd heb en er vrij weinig van weet. Heb alleen de implementatie as is netjes weggewerkt in onze nieuwe .NET Core architectuur nadat mijn collega het gebouwd had.

Hoe doen jullie dan sessie management?

Stel je genereert een JWT token, dan verloopt deze meestal na 10 tot 15 minuten. Als gebruikers actief bezig zijn met jouw SPA, is het niet handig als ze ineens opnieuw moeten inloggen. Dus dan zul je automatisch een nieuw access token moeten aanvragen, met bijvoorbeeld een refresh token.

Maar zodra iemand een refresh token bemachtigt, kan hij oneindig nieuwe tokens aanvragen... dus dat is een vrij nasty scenario als daar geen extra beveiliging op zit.

Of gaan jullie zover als sommige voorbeelden die ik gezien heb, dat elke gelukte request naar een API ook automatisch een nieuw token oplevert? Dat voelt heel wrang voor mij ergens (het mixen van 2 verantwoordelijkheden).

Al met al vind ik de gedachte achter een aparte IdentityServer die als authority fungeert voor het uitdelen en valideren van tokens wel iets hebben, omdat je dan 1 duidelijke afgebakende functie hebt op 1 plek. Bovendien met een beperkte attack surface.

PS
Wat ik wil, lijkt met een eigen implementatie van IResourceOwnerPasswordValidator te kunnen:

https://www.linkedin.com/...4-using-owner-dalvandi-2/

Ik ga er nog een tijdje mee verder spelen. Zou natuurlijk prima een class kunnen maken die IResourceOwnerPasswordValidator implementeert en bijvoorbeeld met Dapper de juiste gegevens erbij haalt.

Schijnt onveilige methode te zijn Ach ja. Next.

"The Resource Owner Password Flow is rarely the recommended approach. It is intended for applications for which no other flow works"

Ik moet er echt rustig voor gaan zitten en het allemaal gaan uitzoeken... meh. Ook fijn dat er blijkbaar mensen zijn die het gewoon implementeren en het verder prima vinden. Er zelfs een hele blog post op LinkedIn aan wenden.

[ Voor 30% gewijzigd door Lethalis op 29-09-2019 21:37 ]

[Sandor_Clegane]

Grijze Vos schreef op zondag 29 september 2019 @ 20:16:
[...]

Wij generaten idd zelf JWT tokens en stoppen die in een cookie. Moet eerlijk zeggen dat ik het niet gebouwd heb en er vrij weinig van weet. Heb alleen de implementatie as is netjes weggewerkt in onze nieuwe .NET Core architectuur nadat mijn collega het gebouwd had.

Wij moesten wel integreren met onze oude zooi, dus we zetten sowieso twee cookies op het moment, voor beiden implementaties.


[...]

Dat doen ze al, die dude werkt voor MS. Vaag dat ze het opnieuw bouwen. Verbeter dan gewoon Newtonsoft.Json, desnoods breng je het onder in een MS namespace.

Dat wist ik niet, is dat sinds kort?

[Styxxy]

Grijze Vos schreef op zondag 29 september 2019 @ 20:16:
[...]
Dat doen ze al, die dude werkt voor MS. Vaag dat ze het opnieuw bouwen. Verbeter dan gewoon Newtonsoft.Json, desnoods breng je het onder in een MS namespace.

De redenering achter de keuze om System.Text.Json te maken staat ook online: https://devblogs.microsof...ew-system-text-json-apis/ en de initiële announcement https://github.com/dotnet/corefx/issues/33115 . De uitleg klinkt goed beredeneert, al kan ik niet zeggen of dat het inderdaad de betere keuze is.

[Grijze Vos]

Lethalis schreef op zondag 29 september 2019 @ 20:17:
[...]
Stel je genereert een JWT token, dan verloopt deze meestal na 10 tot 15 minuten. Als gebruikers actief bezig zijn met jouw SPA, is het niet handig als ze ineens opnieuw moeten inloggen. Dus dan zul je automatisch een nieuw access token moeten aanvragen, met bijvoorbeeld een refresh token.

Onze sessie tokens zijn max 24u geldig, ergens na middernacht lopen ze af.

Sandor_Clegane schreef op zondag 29 september 2019 @ 22:30:
[...]


Dat wist ik niet, is dat sinds kort?

https://twitter.com/james...78719138347495424?lang=en

Al anderhalf jaar.

[Antrax]

Lethalis schreef op zondag 29 september 2019 @ 20:17:
Hoe doen jullie dan sessie management?

Ik heb hier weken voor aan de eetkamer tafel gezeten. Nagedacht hoe het hedendaags zou moeten zijn of gaan. Geconstateerd dat het veel gebruikt wordt zoals voorbeeld projecten het hebben (aka. Hello World).
Ik heb er teveel tijd aan verspilt imho. voor een Symfony backend applicatie. Ik sta nu op het punt om de voorkant te programmeren met React.

Lethalis schreef op zondag 29 september 2019 @ 20:17:
Stel je genereert een JWT token, dan verloopt deze meestal na 10 tot 15 minuten. Als gebruikers actief bezig zijn met jouw SPA, is het niet handig als ze ineens opnieuw moeten inloggen. Dus dan zul je automatisch een nieuw access token moeten aanvragen, met bijvoorbeeld een refresh token. Maar zodra iemand een refresh token bemachtigt, kan hij oneindig nieuwe tokens aanvragen...

Ik gebruik om die reden de refresh token in zijn geheel niet. Bij het genereren van de token gebruik ik `RS256` en ziet mijn token er zo uit:

code:

{
  "iat": 1569791543,
  "nbf": 1569791543,
  "exp": 0,
  "sub": "[e-mail]"
}

De 0 bij exp is met opzet voor dit voorbeeld omdat de geldigheid per environment aangepast kan worden (staging en testing CI hebben bijv. dynamic values) maar die is in de backend: `time() + (60 * 60 * $this->jwtTtl),`. Vraag mij niet waarom ik voor 168 uur (7 dagen) heb gekozen. Ik wilde in eerste instantie de gebruiker niet lastig vallen met opnieuw inloggen maar ik kan er nog voor kiezen om het IP adres te koppelen aan de token (een node _ipAddress_ in de token should do the job) en als die niet overeenkomt moet je gewoon opnieuw inloggen of naast een ip adres de user agent erin zetten?! (Misschien ab-testen in de toekomst, als ik ooit een doel vind voor deze applicatie). In de backend wordt bij iedere request de token gesjeckt. Is het nog geldig? De standaard shizzle. Kan ik met de private key de token decrypten? In de SPA zal ik vervolgens de public key gebruiken (per environment) om vervolgens ook te controleren of er niet gerommeld is met de token.

En uiteraard (want dat gaat gebeuren ) zijn er developers hier in dit draadje die het niet eens zullen zijn met mijn aanpak maar vooralsnog zie ik geen betere oplossing

Lethalis schreef op zondag 29 september 2019 @ 20:17:
Of gaan jullie zover als sommige voorbeelden die ik gezien heb, dat elke gelukte request naar een API ook automatisch een nieuw token oplevert? Dat voelt heel wrang voor mij ergens (het mixen van 2 verantwoordelijkheden).

Ik wil niemand, maar dan ook niemand, dit adviseren te implementeren in welke applicatie dan ook. I rather shoot myself in the foot.

[defiant]

Lethalis schreef op zondag 29 september 2019 @ 20:17:
Hoe doen jullie dan sessie management?
[...]

Al met al vind ik de gedachte achter een aparte IdentityServer die als authority fungeert voor het uitdelen en valideren van tokens wel iets hebben, omdat je dan 1 duidelijke afgebakende functie hebt op 1 plek. Bovendien met een beperkte attack surface.

Je zou eens kunnen kijken naar een oplossing zoals Keycloak, het is enige werk om het te configureren voor .NET aangezien het pakket zich op Java richt, maar het neemt wel heel veel werk uit handen op het gebied van sessie management, JTW, synchronisatie, gebruikersmanagement, etc.

[Sandor_Clegane]

Grijze Vos schreef op zondag 29 september 2019 @ 23:03:
[...]

Onze sessie tokens zijn max 24u geldig, ergens na middernacht lopen ze af.


[...]

https://twitter.com/james...78719138347495424?lang=en

Al anderhalf jaar.

Oh dat valt nog mee dus.

[Hydra]

Lethalis schreef op zondag 29 september 2019 @ 20:17:
Maar zodra iemand een refresh token bemachtigt, kan hij oneindig nieuwe tokens aanvragen... dus dat is een vrij nasty scenario als daar geen extra beveiliging op zit.

Je 'refreshed' een JWT gewoon door met die JWT een nieuwe JWT aan te vragen. Dat is dus gewoon een 'login' maar in plaats van je login credentials gebruik je de JWT. En dit is prima veilig omdat als je die gebruiker z'n toegang in wil trekken bijvoorbeeld, of z'n roles wil wijzigen, dat gewoon kan doen.

Het nadeel van JWTs is dus dat in die 'refresh' periode je geen wijzigingen door kunt voeren. Ik snap ook echt niet dat mensen die dingen 24 uur geldig laten zijn, dan heb je het m.i. helemaal niet begrepen en gebruik je JWTs omdat het 'cool' is, en niet omdat je ze nodig hebt.

Of gaan jullie zover als sommige voorbeelden die ik gezien heb, dat elke gelukte request naar een API ook automatisch een nieuw token oplevert? Dat voelt heel wrang voor mij ergens (het mixen van 2 verantwoordelijkheden).

Als een voorbeeld dat doet, hebben ze het echt niet begrepen, en zou ik weinig waarde hechten aan de mening van de schrijver.

Antrax schreef op zondag 29 september 2019 @ 23:24:
[/code]De 0 bij exp is met opzet voor dit voorbeeld omdat de geldigheid per environment aangepast kan worden (staging en testing CI hebben bijv. dynamic values) maar die is in de backend: `time() + (60 * 60 * $this->jwtTtl),`. Vraag mij niet waarom ik voor 168 uur (7 dagen) heb gekozen.

Omdat je, sorry, de verkeerde tool voor de job gebruikt. Gebruik voor persistence van logins gewoon login-cookies. JWTs zijn vooral bedoeld in grote gedistribueerde systemen waar je niet wil dat voor iedere API call een login server geraakt wordt, die wordt dan eens in de 10 minuten ofzo geraakt (voor de refresh en de initiele logins). Als je JWTs in cookies op gaat slaan, en/of die dingen langer geldig laat zijn dan 10 minuten ofzo, dan sla je aardig de plank mis.

[ Voor 42% gewijzigd door Hydra op 30-09-2019 09:06 ]

[Lethalis]

Hydra schreef op maandag 30 september 2019 @ 09:00:
[...]
Omdat je, sorry, de verkeerde tool voor de job gebruikt. Gebruik voor persistence van logins gewoon login-cookies. JWTs zijn vooral bedoeld in grote gedistribueerde systemen waar je niet wil dat voor iedere API call een login server geraakt wordt, die wordt dan eens in de 10 minuten ofzo geraakt (voor de refresh en de initiele logins). Als je JWTs in cookies op gaat slaan, en/of die dingen langer geldig laat zijn dan 10 minuten ofzo, dan sla je aardig de plank mis.

Daar zeg je inderdaad wel iets... heb ik überhaupt tokens nodig? Mijn projecten zijn niet zo gigantisch dat het boeit en ik zou prima met cookies af kunnen die server side encrypted zijn.

Belangrijkste is eigenlijk dus, dat ze HttpOnly, Secure en SameSite zijn.

[Jantje2000]

Hydra schreef op maandag 30 september 2019 @ 09:00:
[...]


Het nadeel van JWTs is dus dat in die 'refresh' periode je geen wijzigingen door kunt voeren. Ik snap ook echt niet dat mensen die dingen 24 uur geldig laten zijn, dan heb je het m.i. helemaal niet begrepen en gebruik je JWTs omdat het 'cool' is, en niet omdat je ze nodig hebt.

[...]


Omdat je, sorry, de verkeerde tool voor de job gebruikt. Gebruik voor persistence van logins gewoon login-cookies. JWTs zijn vooral bedoeld in grote gedistribueerde systemen waar je niet wil dat voor iedere API call een login server geraakt wordt, die wordt dan eens in de 10 minuten ofzo geraakt (voor de refresh en de initiele logins). Als je JWTs in cookies op gaat slaan, en/of die dingen langer geldig laat zijn dan 10 minuten ofzo, dan sla je aardig de plank mis.

Wat zou je dan moeten gebruiken als je een Angular applicatie data wil laten ophalen vanaf een API. Ik loop nu bijvoorbeeld stage, maar op school heb ik geleerd dat je een backend benadert met een jwt token.
In het eerste jaar moesten we NodeJS gebruiken om een API te schrijven, dan moesten we volgens de leraren JWT gebruiken. In het tweede jaar .NET Core met Angular, ook JWT. Hoe zou het volgens jou dan gebruikt moeten worden?

Ik moet nu tijdens mijn stage ergens programmeren, daar gebruik ik dan dus ook JWT, maar dat zou niet de beste oplossing zijn?

Edit: Angular + REST Api is een eis vanuit het bedrijf

[ThomasG]

Jantje2000 schreef op maandag 30 september 2019 @ 09:34:
[...]

Wat zou je dan moeten gebruiken als je een Angular applicatie data wil laten ophalen vanaf een API. Ik loop nu bijvoorbeeld stage, maar op school heb ik geleerd dat je een backend benadert met een jwt token.
In het eerste jaar moesten we NodeJS gebruiken om een API te schrijven, dan moesten we volgens de leraren JWT gebruiken. In het tweede jaar .NET Core met Angular, ook JWT. Hoe zou het volgens jou dan gebruikt moeten worden?

Ik moet nu tijdens mijn stage ergens programmeren, daar gebruik ik dan dus ook JWT, maar dat zou niet de beste oplossing zijn?

Edit: Angular + REST Api is een eis vanuit het bedrijf

JWT is goed voor API en server-to-server authenticatie, want daar is het voor bedoeld. JWT is niet goed voor sessies. Dus als de client een JWT token naar de API stuurt, is dat prima. Ga je het gebruiken als user session in de client, o.i.d., ben je verkeerd bezig.

[Jantje2000]

ThomasG schreef op maandag 30 september 2019 @ 09:54:
[...]
JWT is goed voor API en server-to-server authenticatie, want daar is het voor bedoeld. JWT is niet goed voor sessies. Dus als de client een JWT token naar de API stuurt, is dat prima. Ga je het gebruiken als user session in de client, o.i.d., ben je verkeerd bezig.

Hoe ik nu werk (en het heb geleerd op school)

De user stuurt username + password in de body naar de server => Server verifieert dat => Server stuurt JWT token als result terug => de user stuurt ieder volgende request de jwt token mee, waarna de server controleert of dit token afkomstig is van de server. Als de user werkelijk is ingelogd ontvangt deze het result van de request, anders een 401 Unauthorized.

Is dat dan zoals het hoort?

[Hydra]

Lethalis schreef op maandag 30 september 2019 @ 09:21:
[...]

Daar zeg je inderdaad wel iets... heb ik überhaupt tokens nodig? Mijn projecten zijn niet zo gigantisch dat het boeit en ik zou prima met cookies af kunnen die server side encrypted zijn.

Tokens of JWTs? Als je een SPA hebt, heb je iets van een session state nodig. Maar daarvoor kun je prima de standaard sessies van je framework voor gebruiken. Als het service to service is, zijn er ook veel opties.

Maar als het een monolitische applicatie is, heb je per definitie geen JWTs nodig. Die hebben dan alleen maar het "kan niet ingetrokken worden" nadeel zonder de schaalbaarheidsvoordelen.

Jantje2000 schreef op maandag 30 september 2019 @ 09:34:
Wat zou je dan moeten gebruiken als je een Angular applicatie data wil laten ophalen vanaf een API. Ik loop nu bijvoorbeeld stage, maar op school heb ik geleerd dat je een backend benadert met een jwt token.
In het eerste jaar moesten we NodeJS gebruiken om een API te schrijven, dan moesten we volgens de leraren JWT gebruiken. In het tweede jaar .NET Core met Angular, ook JWT. Hoe zou het volgens jou dan gebruikt moeten worden?

Ik moet nu tijdens mijn stage ergens programmeren, daar gebruik ik dan dus ook JWT, maar dat zou niet de beste oplossing zijn?

JWTs zijn een oplossing voor een enkel probleem: we hebben een 'login' service die het te druk heeft om elk request te kunnen beoordelen. Het voordeel van JWT t.o.v. 'gewone' tokens heb ik in een blog post beschreven een tijd terug.

Ik vind het wel typisch dat je van docenten JWTs moet gebruiken maar dat niet duidelijk uitgelegd wat de voordelen en nadelen zijn. In monolitische applicaties hebben JWTs gewoon geen nut.

[ Voor 44% gewijzigd door Hydra op 30-09-2019 10:09 ]

[Lethalis]

Jantje2000 schreef op maandag 30 september 2019 @ 09:57:
[...]
Is dat dan zoals het hoort?

"zoals het hoort" is meestal een tijdelijk begrip

Daarom loop ik hier ook nog steeds mee te kutten na 16 jaar als programmeur gewerkt te hebben

Dit is eigenlijk al een apart topic waard.

[Jantje2000]

Lethalis schreef op maandag 30 september 2019 @ 10:07:
[...]

"zoals het hoort" is meestal een tijdelijk begrip

Daarom loop ik hier ook nog steeds mee te kutten na 16 jaar als programmeur gewerkt te hebben

Dit is eigenlijk al een apart topic waard.

Ja dat begrijp ik inderdaad

Ik heb het nu zo geleerd, dat probeer ik dan ook te doen, maar ik probeer wel zo veel mogelijk kwaliteit te leveren, hoewel dat niet altijd lukt. Bijvoorbeeld Google + Microsoft authorization mogelijk maken, terwijl je Angular moet gebruiken, maar dan ook wilt authenticeren op de eigen server. Ik heb het werkend, maar niet mooi

Hydra schreef op maandag 30 september 2019 @ 10:03:
[...]

JWTs zijn een oplossing voor een enkel probleem: we hebben een 'login' service die het te druk heeft om elk request te kunnen beoordelen. Het voordeel van JWT t.o.v. 'gewone' tokens heb ik in een blog post beschreven een tijd terug.

Ik vind het wel typisch dat je van docenten JWTs moet gebruiken maar dat niet duidelijk uitgelegd wat de voordelen en nadelen zijn. In monolitische applicaties hebben JWTs gewoon geen nut.

Je blog ga ik doorlezen!

Verder, een applicatie die een backend heeft van C# en de frontend Angular. Dan zijn het technisch gezien twee applicaties toch? Of spreek je dan nog steeds van Monolitisch? Monolitisch lijkt mij als je maar 1 groot blok hebt toch? Dus gewoon C# met MVC Core bijvoorbeeld, waarbij alles door elkaar heen is gehutseld?

[ Voor 40% gewijzigd door Jantje2000 op 30-09-2019 10:12 ]

[Hydra]

Lethalis schreef op maandag 30 september 2019 @ 10:07:
Dit is eigenlijk al een apart topic waard.

Zit ook serieus te overwegen hier een nieuwe blogpost over te schrijven. I.p.v. over de techniek over de architectuur.

Jantje2000 schreef op maandag 30 september 2019 @ 10:09:
Je blog ga ik doorlezen!

Cool! Feedback/vragen zijn altijd welkom

Verder, een applicatie die een backend heeft van C# en de frontend Angular. Dan zijn het technisch gezien twee applicaties toch? Of spreek je dan nog steeds van Monolitisch? Monolitisch lijkt mij als je maar 1 groot blok hebt toch? Dus gewoon C# met MVC Core bijvoorbeeld, waarbij alles door elkaar heen is gehutseld?

Ik heb het over de back-end; dus dat het gewoon 1 service is. De front-end heeft hier weinig mee te maken.

[ Voor 53% gewijzigd door Hydra op 30-09-2019 10:16 ]

[Jantje2000]

Hydra schreef op maandag 30 september 2019 @ 10:12:
[...]
Ik heb het over de back-end; dus dat het gewoon 1 service is. De front-end heeft hier weinig mee te maken.

Ah oke. Bedoel je dan dat het niet meer monolitisch is als je bijvoorbeeld van het onion model gebruik maakt? Of heb je het dan echt over microservices?

[Hydra]

Jantje2000 schreef op maandag 30 september 2019 @ 10:20:
Ah oke. Bedoel je dan dat het niet meer monolitisch is als je bijvoorbeeld van het onion model gebruik maakt? Of heb je het dan echt over microservices?

Dat laatste, en dan ook op een flinke schaal. Denk aan Netflix.

[Jantje2000]

@Hydra ik heb je blogpost doorgelezen, maar ik zie niet direct het stukje waar jij de voordelen van JWT aangeeft? Of bedoel je dat je er gemakkelijk roles in kunt plaatsen e.d.?

Je zegt dat JWT geen voordelen bieden boven andere token systemen, maar het is ook niet direct verkeerd om JWT te gebruiken hoewel het mogelijk overkill is denk ik?

[Lethalis]

Jantje2000 schreef op maandag 30 september 2019 @ 10:54:
Je zegt dat JWT geen voordelen bieden boven andere token systemen, maar het is ook niet direct verkeerd om JWT te gebruiken hoewel het mogelijk overkill is denk ik?

Ik ben ook allerlei blogs erover aan het lezen en eigenlijk is het een vorm van premature optimization. Je bouwt allerlei flexibiliteit en schaalbaarheid (en complexiteit!) in, zonder dat je het echt nodig hebt.

[Jantje2000]

Lethalis schreef op maandag 30 september 2019 @ 11:02:
[...]

Ik ben ook allerlei blogs erover aan het lezen en eigenlijk is het een vorm van premature optimization. Je bouwt allerlei flexibiliteit en schaalbaarheid (en complexiteit!) in, zonder dat je het echt nodig hebt.

Tja, een tokensysteem heb je sowieso nodig, als de applicatie RESTful moet zijn.

[Hydra]

Jantje2000 schreef op maandag 30 september 2019 @ 10:54:
@Hydra ik heb je blogpost doorgelezen, maar ik zie niet direct het stukje waar jij de voordelen van JWT aangeeft? Of bedoel je dat je er gemakkelijk roles in kunt plaatsen e.d.?

Ik beschrijf in het begin, 2e en 3e alinea. Dus dat het voordeel van JWTs heel specifiek is, dat je niet voor ieder request vanuit een front-end eerst langs een centrale 'login' database hoeft omdat de client iedere keer alle rollen e.d. (claims) meestuurt.

Je zegt dat JWT geen voordelen bieden boven andere token systemen, maar het is ook niet direct verkeerd om JWT te gebruiken hoewel het mogelijk overkill is denk ik?

Een JWT kun je niet 'gewoon' intrekken, je moet wachten tot 'ie expired. Dus als Pietje rare shit doet kun je niet zijn account blokkeren, je kunt alleen nieuwe tokens ongeldig maken. Dus heb je korte (10 minuten ofzo) expiries nodig, en moet je client dus die refresh inbouwen. Dat zijn twee grote nadelen. Als je geen voordelen hebt van een JWT (want; je bent geen Netflix) is het gewoon onhandig om in te bouwen. Het is als software engineer altijd een doel om shit simpel te houden.

Jantje2000 schreef op maandag 30 september 2019 @ 11:03:
Tja, een tokensysteem heb je sowieso nodig, als de applicatie RESTful moet zijn.

Nee hoor, het is gewoon een web applicatie. Je kunt ook prima basic auth gebruiken, of gewoon sessies.

Helaas is het tegenwoordig zo dat er enorme bakken developers zijn die denken dat je meteen naar Oath en JTWs moet grijpen als je een login-system ofzo nodig hebt. Maar dan ondertussen niet snappen wat de voor- en nadelen van JWT en OAuth zijn, en dan enorm complexe systemen bouwen, zonder dat het waarde heeft, waar dan heel veel geld in gaat zitten kwa onderhoud.

Lethalis schreef op maandag 30 september 2019 @ 11:02:
Ik ben ook allerlei blogs erover aan het lezen en eigenlijk is het een vorm van premature optimization. Je bouwt allerlei flexibiliteit en schaalbaarheid (en complexiteit!) in, zonder dat je het echt nodig hebt.

Nouja; ik heb het ook toegepast in een vorig project, een microservice architectuur. En daar was het verre van overkill; het maakte de architectuur heel veel simpeler. Het belangrijkste is dat het gewoon een tool is en het als software engineer belangrijk is alle voors en tegens van je tools te kennen. En daar gaat 't vaak mis.

[ Voor 35% gewijzigd door Hydra op 30-09-2019 11:34 ]

[Jantje2000]

Hydra schreef op maandag 30 september 2019 @ 11:05:
[...]

Nee hoor, het is gewoon een web applicatie. Je kunt ook prima basic auth gebruiken, of gewoon sessies.

Helaas is het tegenwoordig zo dat er enorme bakken developers zijn die denken dat je meteen naar Oath en JTWs moet grijpen als je een login-system ofzo nodig hebt. Maar dan ondertussen niet snappen wat de voor- en nadelen van JWT en OAuth zijn, en dan enorm complexe systemen bouwen, zonder dat het waarde heeft, waar dan heel veel geld in gaat zitten kwa onderhoud.

Ik ben het dan ook nog grotendeels aan het leren, dus het kan inderdaad goed zijn dat ik stomme keuzes maak.

Maar ik snap wat je bedoelt, ik ga eens kijken of een ander token systeem misschien beter is voor ons doel, of dat er toch beter sessies kunnen worden gebruikt in dit geval.

Wat ik niet snap: Wat is dan de reden dat docenten jwt laten gebruiken voor een simpele webapp? Sowieso, als je op internet gaat zoeken voor authenticatie tussen .NET Core en Angular kom je eigenlijk op iedere website wel op jwt uit.

[Lethalis]

Jantje2000 schreef op maandag 30 september 2019 @ 11:15:
[...]
Wat ik niet snap: Wat is dan de reden dat docenten jwt laten gebruiken voor een simpele webapp? Sowieso, als je op internet gaat zoeken voor authenticatie tussen .NET Core en Angular kom je eigenlijk op iedere website wel op jwt uit.

Er bestaan ook dit soort artikelen echter:

http://cryto.net/~joepie9...=dlvr.it&utm_medium=gplus

https://medium.com/@whuys...on-anno-2019-754bc4c29119

Wel probeer ik .NET Core en Angular weg te laten, en in plaats daarvan te zoeken op Single Page Applications en authentication, zodat de discussie iets algemener wordt. En het helpt ook de hipsters er een beetje uit te filteren die alleen hun nieuwe speeltje willen tonen.

[GrooV]

JWT heeft wel meer voordelen dan alleen je login service te ontlasten natuurlijk.

Draai hier een ASP.NET MVC applicatie die JWT gebruikt zonder dat de gebruiker ooit een token ziet, tokens worden vernietigd zodra de gebruiker uitlogt. Reden: Auth0 + IDP.

Jantje2000 schreef op maandag 30 september 2019 @ 11:15:
[...]

Ik ben het dan ook nog grotendeels aan het leren, dus het kan inderdaad goed zijn dat ik stomme keuzes maak.

Maar ik snap wat je bedoelt, ik ga eens kijken of een ander token systeem misschien beter is voor ons doel, of dat er toch beter sessies kunnen worden gebruikt in dit geval.

Wat ik niet snap: Wat is dan de reden dat docenten jwt laten gebruiken voor een simpele webapp? Sowieso, als je op internet gaat zoeken voor authenticatie tussen .NET Core en Angular kom je eigenlijk op iedere website wel op jwt uit.

De reden is dat Authenticatie lastig is, niet lastig om te implementeren maar lastig om het goed te doen. We zijn eindelijk af van alle PHP tutorials die wachtwoorden in plain text opslaan en de boel wagenwijd openzetten voor SQL Injection.

Daarom wordt bij de meeste tutorials gebruik gemaakt van een standaard stack. frontend + backend + identity middleware/service. Bij .net wordt Identityserver gebruikt en bij nodejs wordt pasport.js gebruikt.

Als jij liever je api beveiligd met forms authentication kan dat natuurlijk gewoon, geen probleem. Echter om te voorkomen dat pietje nu weer clientside wachtwoorden gaat opslaan en mee sturen en alles openzet voor CSRF zal je dit niet snel in een tutorial zien. Verder zijn alle voorbeelden van MS nu gericht op Azure en schaalbaarheid wat met een SPA + JWT wel een stuk makkelijker is

[Hydra]

Jantje2000 schreef op maandag 30 september 2019 @ 11:15:
Wat ik niet snap: Wat is dan de reden dat docenten jwt laten gebruiken voor een simpele webapp? Sowieso, als je op internet gaat zoeken voor authenticatie tussen .NET Core en Angular kom je eigenlijk op iedere website wel op jwt uit.

Het is meestal een kwestie van niet beter weten helaas. Docenten hebben vaak niet of nauwelijks industrie-ervaring. Waar het vooral op misgaat is architectuur: dat leer je vooral door jaren aan ervaring. Alleen door ervaring leer je een beetje het kaf van het koren te scheiden kwa blogposts e.d.

Helaas zijn hordes aan developers niet beter dan dat. Klok horen luiden maar niet weten waarde klepel hangt. Dus dan JWT inbouwen, erachter komen dat het niet kunnen intrekken een probleem is, en in plaats van het eruit te slopen en voor een simpele oplossing te gaan, gaan ze dan een eigen 'intrek' service in het systeem inbouwen. Dit soort tunnel-visie, dus niet toe willen geven dat een keuze fout was en deze dan ongedaan maken, komt enorm veel voor.

GrooV schreef op maandag 30 september 2019 @ 11:34:
JWT heeft wel meer voordelen dan alleen je login service te ontlasten natuurlijk.

Welke dan?

[ Voor 8% gewijzigd door Hydra op 30-09-2019 11:38 ]

[Jantje2000]

Hydra schreef op maandag 30 september 2019 @ 11:37:
[...]


Het is meestal een kwestie van niet beter weten helaas. Docenten hebben vaak niet of nauwelijks industrie-ervaring. Waar het vooral op misgaat is architectuur: dat leer je vooral door jaren aan ervaring. Alleen door ervaring leer je een beetje het kaf van het koren te scheiden kwa blogposts e.d.

Helaas zijn hordes aan developers niet beter dan dat. Klok horen luiden maar niet weten waarde klepel hangt. Dus dan JWT inbouwen, erachter komen dat het niet kunnen intrekken een probleem is, en in plaats van het eruit te slopen en voor een simpele oplossing te gaan, gaan ze dan een eigen 'intrek' service in het systeem inbouwen. Dit soort tunnel-visie, dus niet toe willen geven dat een keuze fout was en deze dan ongedaan maken, komt enorm veel voor.

Tja, ik ben het nu nog vooral aan het leren. Ik zit in het derde jaar op een hbo-opleiding, dus als ik blijkbaar een foute keuze heb gemaakt wijzig ik dat graag, zodat ik het de volgende keer gelijk goed kan doen .

Ik ben nu even aan het kijken naar de linkjes die Lethalis stuurde, en nog even aan het uitzoeken wat beter aan miin doel beantwoord, dus ik ben benieuwd wat daar uit komt.

[GrooV]

Hydra schreef op maandag 30 september 2019 @ 11:37:
[...]


Het is meestal een kwestie van niet beter weten helaas. Docenten hebben vaak niet of nauwelijks industrie-ervaring. Waar het vooral op misgaat is architectuur: dat leer je vooral door jaren aan ervaring. Alleen door ervaring leer je een beetje het kaf van het koren te scheiden kwa blogposts e.d.

Helaas zijn hordes aan developers niet beter dan dat. Klok horen luiden maar niet weten waarde klepel hangt. Dus dan JWT inbouwen, erachter komen dat het niet kunnen intrekken een probleem is, en in plaats van het eruit te slopen en voor een simpele oplossing te gaan, gaan ze dan een eigen 'intrek' service in het systeem inbouwen. Dit soort tunnel-visie, dus niet toe willen geven dat een keuze fout was en deze dan ongedaan maken, komt enorm veel voor.


[...]


Welke dan?

Wil je nu dat ik een heel lijstje ga opsommen? Je zet het zelf heel zwart wit hier dat het enige voordeel van JWT is dat het je login service ontlast en dat is gewoon niet zo.

Ik zou zeggen, zet je tunnel-visie tegen JWT aan de kant

JWT is gewoon net zoals alles, pick the right tool for the job. Ik heb menig site ontwikkeld waar intrekken van een sessie totaal niet aan de orde is maar wel graag een horizontaal schaalbare REST api wilden hebben dan kan JWT handig zijn, helemaal als je gebruik kan maken van bestaande componenten

[Hydra]

GrooV schreef op maandag 30 september 2019 @ 12:47:
Wil je nu dat ik een heel lijstje ga opsommen? Je zet het zelf heel zwart wit hier dat het enige voordeel van JWT is dat het je login service ontlast en dat is gewoon niet zo.

Doe niet zo raar zeg. Ik stel je gewoon een vraag? Jij weet kennelijk iets wat ik niet weet, dus ik hoop uit te vinden of ik een blinde vlek heb of niet.

Ik zou zeggen, zet je tunnel-visie tegen JWT aan de kant

Okay, WTF? Ik zeg letterlijk dat ik het toegepast heb. Heb er n.b. een blog post over geschreven, en dat doe je volgens mij niet als ik er iets 'tegen' heb ofwel?

JWT is gewoon net zoals alles, pick the right tool for the job. Ik heb menig site ontwikkeld waar intrekken van een sessie totaal niet aan de orde is maar wel graag een horizontaal schaalbare REST api wilden hebben dan kan JWT handig zijn, helemaal als je gebruik kan maken van bestaande componenten

Je zegt hier letterlijk wat ik zeg, maar heb nog steeds niet uitgelegd welke voordelen er nu meer zijn naast schaalbaarheid.

[ Voor 44% gewijzigd door Hydra op 30-09-2019 12:52 ]

[ard1998]

hoever ik het begrijp gaat JWT niet over schaalbarheid maar over het standaardiseren van authentie. hiermee kan je de gebruiker laten kiezen op welke authenticatieserver hij zijn token(generatie) vertrouwt. Als je het wilt kan je jouw login (om)bouwen tot een service waarmee gebruikers naast het authenticeren voor jouw diencten dit ook kunnen doen voor andere websites (inloggen met ... account)

(mezelf er verder niet in verdiept maar het is mijn eerste opvatting na het lezen van https://jwt.io/introduction/)

[Hydra]

ard1998 schreef op maandag 30 september 2019 @ 13:14:
hoever ik het begrijp gaat JWT niet over schaalbarheid maar over het standaardiseren van authentie. hiermee kan je de gebruiker laten kiezen op welke authenticatieserver hij zijn token(generatie) vertrouwt.

Ik snap echt niet hoe je dat allemaal uit jwt.io haalt. Je hele verhaal slaat als een tang op een varken.
Daarnaast snap ik ook niet zo goed waarom je in een gesprek mengt na even vluchtig een pagina bekeken te hebben. Wat schiet iemand hier mee op?

Schaalbaarheid is veruit het belangrijkste voordeel van JWTs.

Als je het wilt kan je jouw login (om)bouwen tot een service waarmee gebruikers naast het authenticeren voor jouw diencten dit ook kunnen doen voor andere websites (inloggen met ... account)

Dit klinkt alsof je JWT en OAuth door elkaar haalt.

[ Voor 17% gewijzigd door Hydra op 30-09-2019 13:27 ]

[Jantje2000]

ard1998 schreef op maandag 30 september 2019 @ 13:14:
hoever ik het begrijp gaat JWT niet over schaalbarheid maar over het standaardiseren van authentie. hiermee kan je de gebruiker laten kiezen op welke authenticatieserver hij zijn token(generatie) vertrouwt. Als je het wilt kan je jouw login (om)bouwen tot een service waarmee gebruikers naast het authenticeren voor jouw diencten dit ook kunnen doen voor andere websites (inloggen met ... account)

(mezelf er verder niet in verdiept maar het is mijn eerste opvatting na het lezen van https://jwt.io/introduction/)

Hoewel ik nog aan het uitzoeken ben hoe alles nou precies werkt klopt dit helaas echt niet. JWT is juist wel bedoeld voor schaalbaarheid, want doordat het token alleen maar wordt geverifieerd met een secret key, kan er horizontaal gescaled worden. Het idee is dat er nu geen sessie meer nodig is die maar op 1 server staat, waarbij uitloggen alle sessies van alle servers zou moeten laten verwijderen.

Een gebruiker kan bij JWT niet kiezen welke authenticatieserver hij vertrouwt. Het is iets wat aan de backend wordt toegevoegd, waarna gebruikers er gewoon mee moeten dealen. Sterker nog, er is boven water niets van te zien dat er gebruik wordt gemaakt van JWT.

Inloggen met google account, of met Microsoft account wordt niet gedaan met JWT, maar met OAuth.

Edit: wat hydra zegt dus

[GrooV]

Hydra schreef op maandag 30 september 2019 @ 12:50:
[...]


Doe niet zo raar zeg. Ik stel je gewoon een vraag? Jij weet kennelijk iets wat ik niet weet, dus ik hoop uit te vinden of ik een blinde vlek heb of niet.


[...]


Okay, WTF? Ik zeg letterlijk dat ik het toegepast heb. Heb er n.b. een blog post over geschreven, en dat doe je volgens mij niet als ik er iets 'tegen' heb ofwel?


[...]


Je zegt hier letterlijk wat ik zeg, maar heb nog steeds niet uitgelegd welke voordelen er nu meer zijn naast schaalbaarheid.

Je komt een beetje anti-JWT over vandaar Je zegt zelf ook "JWTs zijn een oplossing voor een enkel probleem: we hebben een 'login' service die het te druk heeft om elk request te kunnen beoordelen."

En dat is niet waar in mijn ogen, het is namelijk heel iets anders dan het horizontaal schalen van een REST service, dankzij JWT heb je geen shared sessie of DB met guid's nodig. Dat kan een keuze zijn, los van het te druk hebben. Ook wil je het stuk authenticatie misschien niet bij je API hebben liggen maar bijvoorbeeld bij een SSO provider zoals Auth0 of ADFS

[Hydra]

GrooV schreef op maandag 30 september 2019 @ 15:23:
En dat is niet waar in mijn ogen, het is namelijk heel iets anders dan het horizontaal schalen van een REST service, dankzij JWT heb je geen shared sessie of DB met guid's nodig. Dat kan een keuze zijn, los van het te druk hebben.

En het 'waarom' je dat niet wil hebben is over het algemeen gewoon schaalbaarbeid. Je snapt neem ik aan wel dat het niet hebben van een shared DB geen doel op zich is. Er zit een waarom achter; horizontaal schalen.

Ook wil je het stuk authenticatie misschien niet bij je API hebben liggen maar bijvoorbeeld bij een SSO provider zoals Auth0 of ADFS

Maar dat staat los van JWT. Daarbij ontkom je er niet aan om in services JWT validatie te doen, dus je hebt ergens een shared key (bijvoorbeeld een certificaat) nodig waar je die JWT tegenaan houdt. Of je plakt er een proxy tegenaan die dat voor je doet.

JWTs hebben bijvoorbeeld als voordeel dat je, als je JWTs gebruikt, in dat object een hoop handige info kan proppen die die services dan niet meer extern op hoeven te halen. Maar dit is geen JWT specifiek voorbeeld; een dergelijke user context meesturen vanuit een API-gateway is een bekend pattern wat los staat van JWTs.

Dus nogmaals; ik ben verre van anti-JWT. Ik zie alleen dat dit typisch een tool is waar enorm veel misvattingen over bestaan en als een soort 'gouden hamer' ingezet wordt op plekken waar je beter zonder kunt.

Als je een microservice landschap hebt, kan leven met het niet direct in kunnen trekken, en een issue hebt of gaat krijgen met het horizontaal schalen van authorizatie, dan by all means ga voor JWTs. Maar het zou nooit de default moeten zijn; da's vooral m'n punt.

[GrooV]

Jantje2000 schreef op maandag 30 september 2019 @ 13:40:
[...]

Inloggen met google account, of met Microsoft account wordt niet gedaan met JWT, maar met OAuth.

Edit: wat hydra zegt dus

Dat is OpenID Connect

[Jantje2000]

GrooV schreef op maandag 30 september 2019 @ 15:32:
[...]

Dat is OpenID Connect

Dat dacht ik ook, maar in de Google Cloud Console staan er: "OAuth 2.0-client-ID's" en "Oauth toestemmingsscherm" wat beiden over het externe inloggen gaat. Zie ik iets over het hoofd?

[ThomasG]

GrooV schreef op maandag 30 september 2019 @ 15:23:
[...]

Je komt een beetje anti-JWT over vandaar Je zegt zelf ook "JWTs zijn een oplossing voor een enkel probleem: we hebben een 'login' service die het te druk heeft om elk request te kunnen beoordelen."

En dat is niet waar in mijn ogen, het is namelijk heel iets anders dan het horizontaal schalen van een REST service, dankzij JWT heb je geen shared sessie of DB met guid's nodig. Dat kan een keuze zijn, los van het te druk hebben. Ook wil je het stuk authenticatie misschien niet bij je API hebben liggen maar bijvoorbeeld bij een SSO provider zoals Auth0 of ADFS

Dat is niet dankzij JWT. JWT is namelijk niets anders dan een token formaat. Het kan ook heel goed zonder JWT, bijvoorbeeld door een ander token formaat te gebruiken. Wat je daarvoor nodig hebt is een authenticatie protocol, en dat is JWT niet.

[GrooV]

Jantje2000 schreef op maandag 30 september 2019 @ 15:34:
[...]

Dat dacht ik ook, maar in de Google Cloud Console staan er: "OAuth 2.0-client-ID's" en "Oauth toestemmingsscherm" wat beiden over het externe inloggen gaat. Zie ik iets over het hoofd?

OAuth is authorisatie, OpenID Connect is authenticatie bovenop OAuth

[Hydra]

ThomasG schreef op maandag 30 september 2019 @ 15:35:
Dat is niet dankzij JWT. JWT is namelijk niets anders dan een token formaat.

IMHO is het meer een stukje architectuur. Het exacte formaat is m.i. niet zo relevant (hoewel je natuurlijk gewoon voor een standaard gaat) als welke problemen het oplost en welke problemen het veroorzaakt. Je kunt, als je zelf de client en services bouwt, precies hetzelfde doen met een 'eigen' formaat. Op basis van XML ofzo XWT

[Jantje2000]

Om terug te komen op het oorspronkelijke onderwerp van dit topic: Ik ben bezig met een applicatie tijdens mijn stage. Het idee is dat er medewerkers van klanten kunnen inloggen, maar dit moet ook via Google en Microsoft kunnen. Het gaat om een soort ToDo applicatie, maar dan wat extra functies

Het bedrijf wilde Angular gebruiken, met .NET Core, maar is dit in deze situatie wel handig?

Nadelen:
• Externe login is wat lastiger, omdat dat er in het Identity Framework toch grotendeels vanuit gaat dat je cookies gebruikt met sessions e.d.
• Modellen dubbel moeten definiëren e.d.

Voordelen:
• Het voelt sneller aan.

Het is echter helemaal geen grote applicatie, dus wat zouden jullie doen in zo'n voorbeeld? Zouden jullie voor een SPA gaan, of gewoon voor MVC Core bijvoorbeeld?

[Hydra]

Jantje2000 schreef op maandag 30 september 2019 @ 15:49:
Het is echter helemaal geen grote applicatie, dus wat zouden jullie doen in zo'n voorbeeld? Zouden jullie voor een SPA gaan, of gewoon voor MVC Core bijvoorbeeld?

Ik zou in jouw geval absoluut voor een SPA gaan omdat het voor jou als stagair gewoon een mooie leerervaring is. Ik heb zelf absoluut geen recente ervaring met .Net core, maar ik kan me niet voorstellen dat er geen goeie documentatie is over hoe je daar een API mee bouwt.

Ook ervaring met het integreren van OAuth is waardevol en in mijn ervaring (wel in de Java hoek) is het over 't algemeen ook niet complex. Eigenlijk wat je vooral doet is een externe provider om het mailadres van de gebruiker vragen en, als je daar netjes antwoord op krijgt, ervanuit gaan dat je 'ingelogd' bent.

Je ziet ook wel eens dat mensen een "Facebook" login aanbieden maar dan alleen het mailadres ophalen en alsnog de gebruiker een password laten kiezen. En dan sla je de plak aardig mis. Het voordeel hier is vooral dat, als je geen password van een gebruiker hebt, dit ook niet kan lekken.

[Jantje2000]

Hydra schreef op maandag 30 september 2019 @ 15:59:
[...]


Ik zou in jouw geval absoluut voor een SPA gaan omdat het voor jou als stagair gewoon een mooie leerervaring is. Ik heb zelf absoluut geen recente ervaring met .Net core, maar ik kan me niet voorstellen dat er geen goeie documentatie is over hoe je daar een API mee bouwt.

Ook ervaring met het integreren van OAuth is waardevol en in mijn ervaring (wel in de Java hoek) is het over 't algemeen ook niet complex. Eigenlijk wat je vooral doet is een externe provider om het mailadres van de gebruiker vragen en, als je daar netjes antwoord op krijgt, ervanuit gaan dat je 'ingelogd' bent.

Je ziet ook wel eens dat mensen een "Facebook" login aanbieden maar dan alleen het mailadres ophalen en alsnog de gebruiker een password laten kiezen. En dan sla je de plak aardig mis. Het voordeel hier is vooral dat, als je geen password van een gebruiker hebt, dit ook niet kan lekken.

Ja, angular heeft ook mijn voorkeur inderdaad, omdat ik dan het meest nieuw leer.

OAuth laat ik nu inloggen, door de gebruiker na een klik op de button, een popup te geven die via de server naar Google redirect. Dan log je in, waarna de server jouw oauth gegevens ontvangt. Op basis van die gegevens verstrek ik een jwt token aan de client, waarna de client daarbij kan blijven authenticeren

Api bouwen met .Net Core is heel erg gemakkelijk, het lastigste blijft de authenticatie . Dat moet gelijk goed gebeuren

[ Voor 4% gewijzigd door Jantje2000 op 30-09-2019 16:02 ]

[Hydra]

Jantje2000 schreef op maandag 30 september 2019 @ 16:01:
Ja, angular heeft ook mijn voorkeur inderdaad, omdat ik dan het meest nieuw leer.

OAuth laat ik nu inloggen, door de gebruiker na een klik op de button, een popup te geven die via de server naar Google redirect. Dan log je in, waarna de server jouw oauth gegevens ontvangt. Op basis van die gegevens verstrek ik een jwt token aan de client, waarna de client daarbij kan blijven authenticeren

Prima toch? Wel nog even netjes de expiry op 10m zetten ofzo en de client laten refreshen maar dan ben je er volgens mij al.

[Jantje2000]

Hydra schreef op maandag 30 september 2019 @ 16:03:
[...]


Prima toch? Wel nog even netjes de expiry op 10m zetten ofzo en de client laten refreshen maar dan ben je er volgens mij al.

Ja, ik wist niet 100% zeker of dit een nette oplossing was. Het voelde een beetje hacky .

Als ik dan dus laten expiren na 10 minuten, heb je dan ook nog weer speciale refreshtokens nodig? En zou jij een ander token dan jwt aanraden, of maakt dat ook weer niet heel erg veel uit?

[ThomasG]

Jantje2000 schreef op maandag 30 september 2019 @ 16:01:
[...]

Ja, angular heeft ook mijn voorkeur inderdaad, omdat ik dan het meest nieuw leer.

OAuth laat ik nu inloggen, door de gebruiker na een klik op de button, een popup te geven die via de server naar Google redirect. Dan log je in, waarna de server jouw oauth gegevens ontvangt. Op basis van die gegevens verstrek ik een jwt token aan de client, waarna de client daarbij kan blijven authenticeren

Api bouwen met .Net Core is heel erg gemakkelijk, het lastigste blijft de authenticatie . Dat moet gelijk goed gebeuren

Aangezien je (ASP).NET Core is het handig om Microsoft: Overview of ASP.NET Core Security door te nemen. Daar staat beschreven hoe je het kunt combineren met een SPA en hoe je external logins (zoals Google, Microsoft, Facebook, e.d.) toevoegt.

[Hydra]

Jantje2000 schreef op maandag 30 september 2019 @ 16:04:
Als ik dan dus laten expiren na 10 minuten, heb je dan ook nog weer speciale refreshtokens nodig?

Nee, een refresh kan prima met je huidige token. Je wisselt dus je huidige token in voor een nieuw token.

En zou jij een ander token dan jwt aanraden, of maakt dat ook weer niet heel erg veel uit?

Ik had in deze opzet geen JWT gebruikt voor een 'echte' productie service omdat mijn doel vooral is shit zo simpel mogelijk te houden. Maar je bent stagair dus jouw doel is vooral om zoveel mogelijk te leren. Dus ik zou het lekker met JWTs laten

[Jantje2000]

ThomasG schreef op maandag 30 september 2019 @ 16:07:
[...]
Aangezien je (ASP).NET Core is het handig om Microsoft: Overview of ASP.NET Core Security door te nemen. Daar staat beschreven hoe je het kunt combineren met een SPA en hoe je external logins (zoals Google, Microsoft, Facebook, e.d.) toevoegt.

Die security overview en de api authorization heb ik gebruikt inderdaad, echter is de pagina voor external logins uitsluitend gericht op MVC Core, zonder SPA dus. Dat is dan ook het lastigste stukje

Hydra schreef op maandag 30 september 2019 @ 16:09:
[...]


Nee, een refresh kan prima met je huidige token. Je wisselt dus je huidige token in voor een nieuw token.


[...]


Ik had in deze opzet geen JWT gebruikt voor een 'echte' productie service omdat mijn doel vooral is shit zo simpel mogelijk te houden. Maar je bent stagair dus jouw doel is vooral om zoveel mogelijk te leren. Dus ik zou het lekker met JWTs laten

Duidelijk. Bedankt voor je adviezen!

[ Voor 23% gewijzigd door Jantje2000 op 30-09-2019 16:11 ]

[ThomasG]

Jantje2000 schreef op maandag 30 september 2019 @ 16:09:
[...]

Die security overview en de api authorization heb ik gebruikt inderdaad, echter is de pagina voor external logins uitsluitend gericht op MVC Core, zonder SPA dus. Dat is dan ook het lastigste stukje

Je hebt een stap hoe je ASP.NET Identity gebruikt met een SPA, en hoe je external logins toevoegt aan ASP.NET Identity. Maar die kun je gewoon samen gebruiken. Het is niet alsof externe logins anders behandeld worden zodra ze ingelogd zijn, ze krijgen gewoon een sessie/token, e.d.

[Jantje2000]

ThomasG schreef op maandag 30 september 2019 @ 16:16:
[...]
Je hebt een stap hoe je ASP.NET Identity gebruikt met een SPA, en hoe je external logins toevoegt aan ASP.NET Identity. Maar die kun je gewoon samen gebruiken. Het is niet alsof externe logins anders behandeld worden zodra ze ingelogd zijn, ze krijgen gewoon een sessie/token, e.d.

Ja dat klopt inderdaad. Ik heb het ook op die manier gecombineerd, door een popup te geven die wel gewoon op de server staat. Die haalt de OAuth gegevens op, waarna op basis daarvan een jwt token wordt gegenereerd

[ard1998]

Hydra schreef op maandag 30 september 2019 @ 13:26:
[...]

Ik snap echt niet hoe je dat allemaal uit jwt.io haalt. Je hele verhaal slaat als een tang op een varken.
Daarnaast snap ik ook niet zo goed waarom je in een gesprek mengt na even vluchtig een pagina bekeken te hebben. Wat schiet iemand hier mee op?

Schaalbaarheid is veruit het belangrijkste voordeel van JWTs.

[...]


Dit klinkt alsof je JWT en OAuth door elkaar haalt.

Alseerst, een protocol is ter standaardisatie. De implementatie is hetgeen dat schaalbaar kan zijn.

Zelf ben ik het sterk eens met het artikel van Eran Hamme https://hueniverse.com/oa...road-to-hell-8eec45921529 met. Kort samengevat: Een paar grote bezrijven die de kracht van een authenticatiemethode onderuit halen door de grote pluspunten weg te halen, een systeem met tijdelijke tokens in te stellen om rondom de gecreerde zwakte te werken en dat als good practice aan te bieden. daarnaast een 71 pagins's dik document met oauth2 zwaktes omdat er in de wekgroep over veel belangrijke onderwerpen geen concrete besluiten genomen werden (https://tools.ietf.org/html/rfc6819#page-47). Maar zelf heb ik ook meer dingen waarvan ik vind dat we te veel naar de touwtjes van de grote bedrijven spelen ten koste van de kwaliteit en/of structuur van de projecten.

Wat dat betreft zie ik 1 valiede usecase voor JVT, beveiligen van de authenticatieoverdracht. naar jezelf of naar een derde partij. stop de authenticatiecode in een libary en het maakt het niet uit of het nou SPA of MPA is. schrijf een systeem dat de login / tokengenatie verzorgt en dat dat in een libary of gebruik een libary van een derde partij die je gebruikt bij iedere paginaaanroep. eventueel kan er jwt gebruikt worden. dus doe het dan op z'n minst goed met een MPA. scheelt een hoop onnodige downoad en het maakt de website beter navigeerbaar voor iedereen, ook dezene die gebruik moeten maken van acessabillity tools. Als je toch goed bezig ben, vervand de "ik ben een frontend developer en kan aleen maar met frameworks werken" code en versimpel je backend door de "ik haat sql en database ontwerpen, dus ik gooi er tig lagen abstractie tussen" te vervangen door nette sql oplossingen op basis van een database ontwerp . Dit functioneert als je database structuur en zijn documentatie.

[Hydra]

ard1998 schreef op maandag 30 september 2019 @ 17:12:
Zelf ben ik het sterk eens met het artikel van Eran Hamme https://hueniverse.com/oa...road-to-hell-8eec45921529 met.

Je begint weer over OAuth terwijl we het over JWT hadden. Heb verder weinig trek in een hoop random gezwets te moeten beantwoorden, sorry.

[ Voor 32% gewijzigd door Hydra op 30-09-2019 17:46 ]

[ard1998]

Hydra schreef op maandag 30 september 2019 @ 13:26:
[...]


Ik snap echt niet hoe je dat allemaal uit jwt.io haalt. Je hele verhaal slaat als een tang op een varken.
Daarnaast snap ik ook niet zo goed waarom je in een gesprek mengt na even vluchtig een pagina bekeken te hebben. Wat schiet iemand hier mee op?

Schaalbaarheid is veruit het belangrijkste voordeel van JWTs.


Dit klinkt alsof je JWT en OAuth door elkaar haalt.

Hydra schreef op maandag 30 september 2019 @ 17:45:
[...]


Je begint weer over OAuth terwijl we het over JWT hadden. Heb verder weinig trek in een hoop random gezwets te moeten beantwoorden, sorry.

Zegt degeen die in eerste instantie Oath in de mond nam waarop ik reageer met dat ik me niet daarin vergis want ... en ik zie het gebruik van JWT in de volgende context. Ja, mijzelf zuidelijk maken is niet mijn sterkste punt, dat weet ik

[Lethalis]

@Jantje2000 @Hydra Het is mij gelukt om een Angular SPA te laten inloggen op een .NET Core API met simpelweg cookie authentication

Het .NET Core framework beheert dan de sessie voor mij. Ik moest met de volgende zaken rekening houden:

• De Angular app doet zijn requests met de withCredentials optie. Authenticeren gaat gewoon door een POST te doen op een /api/auth/authenticate met credentials.
• Nadat ik de credentials heb gecontroleerd, laat ik het .NET Core framework een cookie maken door HttpContext.SignInAsync aan te roepen ( https://docs.microsoft.co...ookie?view=aspnetcore-3.0 ).
• In mijn Angular router module gebruik ik een guard die een GET request doet op /api/auth/check. Krijg ik een 401 terug, dan navigeer ik naar het LoginComponent:
  
  code:
  

  @Injectable({
    providedIn: 'root'
  })
  export class AuthGuardService implements CanActivate {
  
    constructor(private backend: BackendService, private router: Router) { }
  
    canActivate(route: ActivatedRouteSnapshot, state: RouterStateSnapshot): boolean | UrlTree | Observable<boolean | UrlTree> | Promise<boolean | UrlTree> {
      return this.backend.authCheck().pipe(
        map(result => { 
          if (result) return true;
          this.router.navigate(['/login']);
        })
      );
    }
  }

  
  En de code in de BackendService:
  
  code:
  

    authCheck(): Observable<boolean> {
      let url = `${this.backendUrl}/api/auth/check`;
  
      return this.http.get(url, { withCredentials: true }).pipe(
        map(data => true),
        catchError(err => of(false))
      );
    }

  
  Hier zou ik nog wat meer error handling kunnen doen, dat ik echt naar een 401 kijk, zodat de sessie niet verbroken wordt door andere communicatiefouten.
• Ik moest .NET Core wel even vertellen dat hij een 401 moet geven en niet moet proberen naar een eigen login pagina te redirecten.
  
  code:
  

        services
          .AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
          .AddCookie(options =>
          {
            options.Events.OnRedirectToLogin = (context) =>
            {
              context.Response.StatusCode = 401;
              return Task.CompletedTask;
            };
          });

• Uiteraard gaat alles via HTTPS.
• Ik moest de Cookie policy nog aanpassen, zodat de cookie HttpOnly, SameSite en ook Secure zijn:
  
  code:
  

        var cookiePolicyOptions = new CookiePolicyOptions
        {
          MinimumSameSitePolicy = SameSiteMode.Strict,
          HttpOnly = HttpOnlyPolicy.Always,
          Secure = CookieSecurePolicy.SameAsRequest // Voor development
        };
        app.UseCookiePolicy(cookiePolicyOptions);

• ASP.NET Core versleutelt automatisch de cookie voor mij (ASP.NET Core Data Protection). Mocht ik in de toekomst ooit moeten load balancen, dan is het mogelijk om meerdere instanties dezelfde key ring te laten gebruiken, zodat alles blijft werken (al ga ik er niet vanuit dat dit ooit nodig is voor dit project).

Overwegingen om voor cookie auth te kiezen:

• Schaalbaarheid is geen issue voor dit project. Het vervangt een oude management console die al 10 jaar lang op 1 server gehost werd. Het project wordt nieuw leven ingeblazen, maar zal naar alle waarschijnlijkheid zelfs minder users hebben dan de oude console ooit had (50 tot 100 geprojecteerd).
• Het is veel simpeler in te bouwen dan een JWT based auth met IdentityServer etc.
• Het is mogelijk een sessie te killen.

Mochten jullie nog op- en aanmerkingen hebben, graag

[GrooV]

Lethalis schreef op maandag 30 september 2019 @ 22:05:
@Jantje2000 @Hydra Het is mij gelukt om een Angular SPA te laten inloggen op een .NET Core API met simpelweg cookie authentication

Het .NET Core framework beheert dan de sessie voor mij. Ik moest met de volgende zaken rekening houden:

• De Angular app doet zijn requests met de withCredentials optie. Authenticeren gaat gewoon door een POST te doen op een /api/auth/authenticate met credentials.
• Nadat ik de credentials heb gecontroleerd, laat ik het .NET Core framework een cookie maken door HttpContext.SignInAsync aan te roepen ( https://docs.microsoft.co...ookie?view=aspnetcore-3.0 ).
• In mijn Angular router module gebruik ik een guard die een GET request doet op /api/auth/check. Krijg ik een 401 terug, dan navigeer ik naar het LoginComponent:
  
  code:
  

  @Injectable({
    providedIn: 'root'
  })
  export class AuthGuardService implements CanActivate {
  
    constructor(private backend: BackendService, private router: Router) { }
  
    canActivate(route: ActivatedRouteSnapshot, state: RouterStateSnapshot): boolean | UrlTree | Observable<boolean | UrlTree> | Promise<boolean | UrlTree> {
      return this.backend.authCheck().pipe(
        map(result => { 
          if (result) return true;
          this.router.navigate(['/login']);
        })
      );
    }
  }

  
  En de code in de BackendService:
  
  code:
  

    authCheck(): Observable<boolean> {
      let url = `${this.backendUrl}/api/auth/check`;
  
      return this.http.get(url, { withCredentials: true }).pipe(
        map(data => true),
        catchError(err => of(false))
      );
    }

  
  Hier zou ik nog wat meer error handling kunnen doen, dat ik echt naar een 401 kijk, zodat de sessie niet verbroken wordt door andere communicatiefouten.
• Ik moest .NET Core wel even vertellen dat hij een 401 moet geven en niet moet proberen naar een eigen login pagina te redirecten.
  
  code:
  

        services
          .AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
          .AddCookie(options =>
          {
            options.Events.OnRedirectToLogin = (context) =>
            {
              context.Response.StatusCode = 401;
              return Task.CompletedTask;
            };
          });

• Uiteraard gaat alles via HTTPS.
• Ik moest de Cookie policy nog aanpassen, zodat de cookie HttpOnly, SameSite en ook Secure zijn:
  
  code:
  

        var cookiePolicyOptions = new CookiePolicyOptions
        {
          MinimumSameSitePolicy = SameSiteMode.Strict,
          HttpOnly = HttpOnlyPolicy.Always,
          Secure = CookieSecurePolicy.SameAsRequest // Voor development
        };
        app.UseCookiePolicy(cookiePolicyOptions);

• ASP.NET Core versleutelt automatisch de cookie voor mij (ASP.NET Core Data Protection). Mocht ik in de toekomst ooit moeten load balancen, dan is het mogelijk om meerdere instanties dezelfde key ring te laten gebruiken, zodat alles blijft werken (al ga ik er niet vanuit dat dit ooit nodig is voor dit project).

Overwegingen om voor cookie auth te kiezen:

• Schaalbaarheid is geen issue voor dit project. Het vervangt een oude management console die al 10 jaar lang op 1 server gehost werd. Het project wordt nieuw leven ingeblazen, maar zal naar alle waarschijnlijkheid zelfs minder users hebben dan de oude console ooit had (50 tot 100 geprojecteerd).
• Het is veel simpeler in te bouwen dan een JWT based auth met IdentityServer etc.
• Het is mogelijk een sessie te killen.

Mochten jullie nog op- en aanmerkingen hebben, graag

Cookie != Session

Hier staat nog wat meer op de MS site, mocht je ook Authorization willen toevoegen: https://docs.microsoft.co...ookie?view=aspnetcore-3.0. Die link had je al gevonden

Ook moet je wel de Session aan hebben staan en het Cookie laten verlopen anders heb je het zelfde als met JWT

Verder opletten dat je geen redirect doet na het uitloggen omdat dat anders niet werkt en denk wel aan CSRF

[Lethalis]

GrooV schreef op dinsdag 1 oktober 2019 @ 08:10:
[...]
Cookie != Session

Ook moet je wel de Session aan hebben staan en het Cookie laten verlopen anders heb je het zelfde als met JWT

Verder opletten dat je geen redirect doet na het uitloggen omdat dat anders niet werkt en denk wel aan CSRF

Ik neem aan dat je bedoelt dat ik de SessionMiddleware moet gebruiken en dat dit iets anders is dan een cookie? (dat 1 van de mogelijkheden is om als session identifier te gebruiken)

code:

      services.AddSession(options =>
      {
        options.IdleTimeout = TimeSpan.FromMinutes(10);
        options.Cookie.HttpOnly = true;
        options.Cookie.IsEssential = true;
      });

      app.UseSession();

Voor de rest gebruik ik de volgende AuthenticationProperties bij het aanmelden:

code:

          var claimsIdentity = new ClaimsIdentity(logon.GetClaims(), CookieAuthenticationDefaults.AuthenticationScheme);
          var authProperties = new AuthenticationProperties
          {
            AllowRefresh = true,
            ExpiresUtc = DateTimeOffset.UtcNow.AddMinutes(10),
            RedirectUri = null
          };

          HttpContext.SignInAsync(
            CookieAuthenticationDefaults.AuthenticationScheme,
            new ClaimsPrincipal(claimsIdentity),
            authProperties);
        }

Het idee is dat authentication tickets na 10 minuten verlopen, maar omdat AllowRefresh aan staat, zou je een nieuwe moeten krijgen als je binnen die 10 minuten actief op de applicatie bent.

Wat CSRF betreft, zet ik de cookies met SameSite (Strict) en HttpOnly en ook Secure.

[Jantje2000]

Lethalis schreef op dinsdag 1 oktober 2019 @ 09:11:
[...]

Ik neem aan dat je bedoelt dat ik de SessionMiddleware moet gebruiken en dat dit iets anders is dan een cookie? (dat 1 van de mogelijkheden is om als session identifier te gebruiken)

code:

      services.AddSession(options =>
      {
        options.IdleTimeout = TimeSpan.FromMinutes(10);
        options.Cookie.HttpOnly = true;
        options.Cookie.IsEssential = true;
      });

      app.UseSession();

Voor de rest gebruik ik de volgende AuthenticationProperties bij het aanmelden:

code:

          var claimsIdentity = new ClaimsIdentity(logon.GetClaims(), CookieAuthenticationDefaults.AuthenticationScheme);
          var authProperties = new AuthenticationProperties
          {
            AllowRefresh = true,
            ExpiresUtc = DateTimeOffset.UtcNow.AddMinutes(10),
            RedirectUri = null
          };

          HttpContext.SignInAsync(
            CookieAuthenticationDefaults.AuthenticationScheme,
            new ClaimsPrincipal(claimsIdentity),
            authProperties);
        }

Het idee is dat authentication tickets na 10 minuten verlopen, maar omdat AllowRefresh aan staat, zou je een nieuwe moeten krijgen als je binnen die 10 minuten actief op de applicatie bent.

Wat CSRF betreft, zet ik de cookies met SameSite (Strict) en HttpOnly en ook Secure.

Netjes gemaakt! Ik blijf zelf gewoon JWT gebruiken (omdat ik lui ben en het er nu toch al best goed werkend in zit ), maar dit is inderdaad best een nette oplossing.

Over het horizontale scalen, krijg je met zo'n cookie oplossing niet alsnog het probleem dat de sessie er op de ene server wel is en op de andere niet. Dus dat je dan met loadbalancing bij een uitlog de sessie van alle servers moet gaan laten verwijderen?

[Lethalis]

Jantje2000 schreef op dinsdag 1 oktober 2019 @ 09:17:
[...]
Over het horizontale scalen, krijg je met zo'n cookie oplossing niet alsnog het probleem dat de sessie er op de ene server wel is en op de andere niet. Dus dat je dan met loadbalancing bij een uitlog de sessie van alle servers moet gaan laten verwijderen?

Yes. Ik heb hier dan ook voor gekozen, omdat ik niet verwacht dat ik horizontaal hoef te schalen.

Hoe dit met .NET Core moet, heb ik eerlijk gezegd geen ervaring mee... maar vroeger met WebForms e.d. had je hier meerdere mogelijkheden voor. Je kon een losse SessionState service draaien, je kon de state ook in SQL Server opslaan (wat takke traag was), enzovoorts.

Dus hier zullen voor .NET Core ook oplossingen bestaan.

Maar eerlijk gezegd, zou ik dan wel JSON Web Tokens inbouwen.

Alleen het idee is dat wanneer de applicatie toch weinig gebruikers heeft, het totaal niet boeit en je net zo goed voor een simpele oplossing kunt kiezen.

[Jantje2000]

Lethalis schreef op dinsdag 1 oktober 2019 @ 09:22:
[...]

Yes. Ik heb hier dan ook voor gekozen, omdat ik niet verwacht dat ik horizontaal hoef te schalen.

Hoe dit met .NET Core moet, heb ik eerlijk gezegd geen ervaring mee... maar vroeger had je hier meerdere mogelijkheden voor. Je kon een losse SessionState service draaien, je kon de state ook in SQL Server opslaan (wat takke traag was), enzovoorts.

Dus hier zullen voor .NET Core ook oplossingen bestaan.

Maar eerlijk gezegd, zou ik dan wel JSON Web Tokens inbouwen.

Alleen het idee is dat wanneer de applicatie toch weinig gebruikers heeft, het totaal niet boeit en je net zo goed voor een simpele oplossing kunt kiezen.

Ja precies.

De applicatie waar ik nu aan bezig ben moet gaan worden gebruikt door klanten van dit bedrijf. Ik weet natuurlijk niet hoe groot het gaat worden, maar ik kan met goed voorstellen dat er horizontaal gescaled zou moeten gaan worden. (Hoewel we op Azure draaien, dus ik zal daar dan weer niet extreem veel aandacht aan hoeven te besteden.)

Daarom had ik in eerste instantie ook gekozen voor JWT (ook omdat mijn docenten geleerd hadden dat dat een best practice is voor API's

[Hydra]

Jantje2000 schreef op dinsdag 1 oktober 2019 @ 09:17:
Over het horizontale scalen, krijg je met zo'n cookie oplossing niet alsnog het probleem dat de sessie er op de ene server wel is en op de andere niet. Dus dat je dan met loadbalancing bij een uitlog de sessie van alle servers moet gaan laten verwijderen?

De laatste keer dat ik met .Net werkte, in 2005 ofzo, kon je vrij simpel sessie state sharen tussen instances via MS SQL. Dat was toen al practisch plug and play. Natuurlijk heb je dan je sessie store als een bottleneck, maar het gaat lang duren voordat MS SQL (of een andere database) het te druk gaat krijgen met dergelijke simpele key-lookups.

Sowieso zou ik er altijd vanuit gaan dat je minimaal 2 instances van je service hebt draaien gewoon puur voor de fail-over. Stateful services, die dus zelf zaken in memory houden (behalve caches), zijn over 't algemeen een slecht idee. Het is simpel om direct goed te doen maar lastig naderhand te moeten fixen.

[Jantje2000]

Hydra schreef op dinsdag 1 oktober 2019 @ 09:55:
[...]


De laatste keer dat ik met .Net werkte, in 2005 ofzo, kon je vrij simpel sessie state sharen tussen instances via MS SQL. Dat was toen al practisch plug and play. Natuurlijk heb je dan je sessie store als een bottleneck, maar het gaat lang duren voordat MS SQL (of een andere database) het te druk gaat krijgen met dergelijke simpele key-lookups.

Sowieso zou ik er altijd vanuit gaan dat je minimaal 2 instances van je service hebt draaien gewoon puur voor de fail-over. Stateful services, die dus zelf zaken in memory houden (behalve caches), zijn over 't algemeen een slecht idee. Het is simpel om direct goed te doen maar lastig naderhand te moeten fixen.

Ja, en dit is natuurlijk geen .Net ding. Uiteindelijk is het gewoon een concept dat je gebruikt, of het nou in C# of in Java is, in beide gevallen wil je sessions over de servers kunnen delen.

Hoewel het natuurlijk mogelijk is dat Spring weer een eigen session management iets heeft, waardoor het gemakkelijker is dan door middel van database lookups.

[Lethalis]

Jantje2000 schreef op dinsdag 1 oktober 2019 @ 09:57:
[...]

Ja, en dit is natuurlijk geen .Net ding. Uiteindelijk is het gewoon een concept dat je gebruikt, of het nou in C# of in Java is, in beide gevallen wil je sessions over de servers kunnen delen.

Hoewel het natuurlijk mogelijk is dat Spring weer een eigen session management iets heeft, waardoor het gemakkelijker is dan door middel van database lookups.

Voor .NET Core kun je trouwens "Distributed Caching" gebruiken:

https://docs.microsoft.co...buted?view=aspnetcore-3.0

Dit slaat de state in SQL Server op, maar je kunt ook REDIS gebruiken. Met Spring kun je dit ook doen en heb je uiteindelijk dus hetzelfde effect:

https://medium.com/@gvnix...ession-redis-bdc6f7438cc3

PS
Dus als ik de door mij gekozen oplossing beter wil verwoorden:
- Ik heb een monolithische applicatie die het session management van het framework gebruikt.
- Om SPA's te ondersteunen gebruik ik cookies met een session identifier er in en heb ik het framework ook verteld dat cookies essentieel zijn.
- Mocht ik ooit horizontaal moeten schalen, dan kan ik de session state delen met meerdere instanties door een in memory cache zoals REDIS te gebruiken, of kan ik de state zelfs persistent maken door hem in SQL Server op te slaan.

Dat laatste kan trouwens handig zijn als je nog (zoals ik) in het stenen tijdperk leeft en zelf on premises servers draait. Bij een onverwachte reboot van een machine blijven de sessies van de gebruikers dus heel (als je niet te lang uit de lucht bent).

Bij een in memory cache moeten ze allemaal opnieuw inloggen. Aan de andere kant geeft een in memory cache betere performance.

Dus het is - zoals altijd - een afweging.

[ Voor 36% gewijzigd door Lethalis op 01-10-2019 10:31 ]

[Lethalis]

@Hydra @Jantje2000
Er is een probleem met de gekozen oplossing... althans daar lijkt het erg op momenteel. Op het moment dat de API op een ander domein staat dan de SPA, dan wordt de cookie gezien als een third party cookie en zullen veel moderne browsers weigeren de cookie op te slaan (in een poging privacy schendende tracking cookies tegen te gaan).

En dan werkt het dus simpelweg niet meer.

Tegen de JWT stroming inzwemmen heeft dus ook zo zijn nadelen als je met SPA's werkt en gewend bent een scheiding tussen SPA en API aan te brengen (ook qua deployment).

Plaats ik de API in hetzelfde domein, dan werkt het weer. Dus ik weet helaas vrij zeker dat het hieraan ligt.

Nu kan ik met een reverse proxy er wel voor zorgen dat de API altijd van hetzelfde domein lijkt te komen, maar dat maakt het qua deployment wel weer complexer.

Als jij Pietje bent en je hebt 10 users, dan kunnen die bij ons vaak inloggen op een eigen (sub)domein om het makkelijker voor ze te maken de URL te onthouden.

Wat zijn jullie gedachten hierover?

PS
Een andere oplossing zou zijn het inlogscherm volledig server side te doen met MVC. Dan navigeer je echt naar de URL toe. Maar ik vind dat eigenlijk niet zo mooi...

@Hydra
Hoe deploy jij SPA's die met sessions van een server side framework werken? Laat je de SPA dan ook hosten door de server side applicatie? (in het geval van .NET Core zou dat betekenen dat ik de SPA in de wwwroot map plaats bijvoorbeeld)

[ Voor 32% gewijzigd door Lethalis op 02-10-2019 16:39 ]

[Jantje2000]

Lethalis schreef op woensdag 2 oktober 2019 @ 16:10:
@Hydra @Jantje2000
Er is een probleem met de gekozen oplossing... althans daar lijkt het erg op momenteel. Op het moment dat de API op een ander domein staat dan de SPA, dan wordt de cookie gezien als een third party cookie en zullen veel moderne browsers weigeren de cookie op te slaan (in een poging privacy schendende tracking cookies tegen te gaan).

En dan werkt het dus simpelweg niet meer.

Tegen de JWT stroming inzwemmen heeft dus ook zo zijn nadelen als je met SPA's werkt en gewend bent een scheiding tussen SPA en API aan te brengen (ook qua deployment).

Plaats ik de API in hetzelfde domein, dan werkt het weer. Dus ik weet helaas vrij zeker dat het hieraan ligt.

Nu kan ik met een reverse proxy er wel voor zorgen dat de API altijd van hetzelfde domein lijkt te komen, maar dat maakt het qua deployment wel weer complexer.

Als jij Pietje bent en je hebt 10 users, dan kunnen die bij ons vaak inloggen op een eigen (sub)domein om het makkelijker voor ze te maken de URL te onthouden.

Wat zijn jullie gedachten hierover?

PS
Een andere oplossing zou zijn het inlogscherm volledig server side te doen met MVC. Dan navigeer je echt naar de URL toe. Maar ik vind dat eigenlijk niet zo mooi...

Wil je de applicatie per se op een ander domein draaien? Misschien niet het alleernetsts, maar in .NET Core gebruik je in de start file

code:

services.addMvc()

. In plaats daarvan maak je dan gebruik van

code:

services.addSpa()

(of zoiets, maar hier lijkt het wel op), waarna dat probleem zou moeten zijn opgelost.

Dan krijg je in je project in plaats van een views folder een clientapp folder, waarin de Angular app komt te staan. Deze runt dan dus echt op hetzelfde domein.

Dan heb je echter geen compleet gescheiden front en backend meer, dus misschien verlies je dan voordelen die de redenen waren dat jij in dit project voor SPA hebt gekozen?

[ Voor 4% gewijzigd door Jantje2000 op 02-10-2019 16:38 ]

[Lethalis]

Jantje2000 schreef op woensdag 2 oktober 2019 @ 16:37:
[...]
Wil je de applicatie per se op een ander domein draaien?

Dan krijg je in je project in plaats van een views folder een clientapp folder, waarin de Angular app komt te staan. Deze runt dan dus echt op hetzelfde domein.

Dan heb je echter geen compleet gescheiden front en backend meer, dus misschien verlies je dan voordelen die de redenen waren dat jij in dit project voor SPA hebt gekozen?

Dit hoeft niet per se een probleem te zijn, maar ik ben wel benieuwd hoe hier tegenaan wordt gekeken.

Op zich kan ik zelfs het hele frontend / SPA ontwikkelen in de wwwroot van mijn .NET Core applicatie en het als 1 geheel deployen. Microsoft heeft de wwwroot ook om die reden in het leven geroepen.

De reden om voor een SPA te gaan, is voornamelijk interactiviteit. Omdat de projecten een vrij hoge mate van dynamische content hebben, is het bouwen ervan met MVC een soort schizofrene oplossing, omdat je uiteindelijk toch een soort tweede applicatie in JavaScript ernaast aan het bouwen bent voor alle dynamische content.

Als het dan toch al die kant op gaat, kun je net zo goed een aparte SPA hebben en krijg je meteen ook een natuurlijkere development flow erbij (betere scheiding client vs server side code).

[robbens]

Zoals @Jantje2000 het voorlegt gaan we ervan uit dat je in één project werkt. Angular, react, vue.js en andere frameworks hebben ondersteuning voor observables (Javascript / Typescript: https://angular.io/guide/observables). Door dit te introduceren kun je een échte afscheiding maken tussen front- en back-end. Als je je back-end via REST draait, kun je gebruik maken van technologieën zoals async gecombineerd met observables.

Dit zorgt ervoor dat je meerdere pagina's kan transformeren in een SPA (je gebruikt bv. de angular routing module) - en je data in een back-end logisch afgesplitst heb. Dan ben je ook alvast begonnen aan een stukje SOLID: wie wordt daar niet blij van?

Edit: als je complexe data hebt die ook nog is dynamisch is kan ik MVC niet aanraden. Dan is de bovenstaande aanpak logischer (en vaak ook een heel stuk meer solide omdat je geen spaghetti-code hebt).

[ Voor 12% gewijzigd door robbens op 02-10-2019 16:48 ]

[Lethalis]

@robbens De discussie MVC vs SPA is eigenlijk al voorbij als je dit topic helemaal doorleest Eigenlijk zou ik een nieuw topic aan moeten maken voor waar ik nu mee bezig ben: het managen van sessies in SPA's.

Waarbij de discussie vooral is: gebruik je gesignde tokens zoals JWT, of laat je de sessie managen door een server side framework dat bijvoorbeeld een versleutelde cookie genereert met een sessie id.

Op het moment dat je voor die laatste oplossing kiest, kun je dus ook met andere zaken te maken krijgen, zoals de herkomst van de cookie (het mag geen third party cookie zijn) of bepaalde aspecten bij horizontale schaalbaarheid (sessies bewaren in centrale store bijv).

Het oorspronkelijke argument om niet voor JWT te kiezen, is met name dat voor kleine projecten de voordelen van JWT nauwelijks opwegen tegen de nadelen ervan.

Anyways... ik ben een beetje een web dinosaurus die up to speed probeert te komen Meeste ervaring heb ik ooit met ASP.NET Web Forms opgedaan Daarna jaren lang alleen maar Windows applicaties geprogrammeerd, dus vergeef me enige naïviteit op dit front.

Ik heb wel met Angular aan bestaande projecten gewerkt, alleen ik kom er gaandeweg wel achter dat mijn collega's ook niet altijd de meest weloverwogen beslissingen hebben genomen (zoals JWT tokens genereren die uren lang geldig blijven, omdat het refreshen ervan "lastig" is).

Uiteraard ben ik weer degene die tot op de bodem alles wil uitzoeken en begrijpen, zodat ik geen shit aflever. Maar ook omdat ik mezelf geen slechte gewoontes wil aanleren.

[robbens]

@Lethalis Ah, sorry, da's mijn fout.

JWT's zijn handig (let op dat je ze goed opzet!). Het is ietsjes lastiger in het begin, maar als je het doorhebt is het een hele fijne methodiek om mee te werken.

Hier geldt de aloude discussie voor:
Wat wil je bereiken, en wat wil je beveiligen?
Heb je zwaarwegende persoonlijke gegevens dan zou ik een combinatie aanpak doen. Gebruik je de login alleen om wat zelf-verzamelde gegevens van de gebruiker te laten zien dan zou ik het simpeler oplossen. De beste manier om een goede, doordachte keuze te maken is om een kosten-batenanalyse uit te voeren op jouw project.

[Jantje2000]

@Lethalis https://docs.microsoft.co...re-3.0&tabs=visual-studio dat bedoelde ik.

Maar door dit te gebruiken doet het dotnet run commando ook gelijk een ng serve op hetzelfde domein. Dus dat is iets gemakkelijker dan de wist folder in de wwwroot te plaatsen

[Hydra]

Lethalis schreef op woensdag 2 oktober 2019 @ 16:10:
@Hydra @Jantje2000
Er is een probleem met de gekozen oplossing... althans daar lijkt het erg op momenteel. Op het moment dat de API op een ander domein staat dan de SPA, dan wordt de cookie gezien als een third party cookie en zullen veel moderne browsers weigeren de cookie op te slaan (in een poging privacy schendende tracking cookies tegen te gaan).

Ik snap niet wat dat met JWTs te maken heeft. Een JWT wordt meestal via een Auth header meegestuurd (Authorization: Bearer <Token>). An sich kan het met een cookie maar is niet standaard.

Hetzelfde geldt voor sessions; dit wordt vaak via cookies gedaan maar hoeft natuurlijk absoluut niet. Je kunt in de meeste frameworks zelf inregelen waar die session ID vandaan moet komen. Dit kan ook (wederom) gewoon een token in een header zijn.

@Hydra
Hoe deploy jij SPA's die met sessions van een server side framework werken? Laat je de SPA dan ook hosten door de server side applicatie? (in het geval van .NET Core zou dat betekenen dat ik de SPA in de wwwroot map plaats bijvoorbeeld)

Ik server over het algemeen meestal zowel de SPA als de API via een reverse proxy (Traefik bijvoorbeeld). Dan is wat daar 'achter' zit niet meer relevant, dat komt volgens de browser allemaal van hetzelfde domain.

Ik gebruik over 't algemeen geen sessions trouwens maar gewoon een login met een secret bearer token.

[Lethalis]

Ik heb voor de discussie over sessies een apart topic aangemaakt:

Session management en Single Page Applications

[GrooV]

Overigens met een SPA kan je wel heel goedkoop alles in Azure hosten, Static website in Azure Storage, API in Azure Functions, "DB" in Azure Table Storage.

Kost geen drol en je kan maximaal schalen, kan natuurlijk ook een afweging zijn

[Antrax]

Hydra schreef op maandag 30 september 2019 @ 09:00:
Omdat je, sorry, de verkeerde tool voor de job gebruikt. Gebruik voor persistence van logins gewoon login-cookies. JWTs zijn vooral bedoeld in grote gedistribueerde systemen waar je niet wil dat voor iedere API call een login server geraakt wordt, die wordt dan eens in de 10 minuten ofzo geraakt (voor de refresh en de initiele logins). Als je JWTs in cookies op gaat slaan, en/of die dingen langer geldig laat zijn dan 10 minuten ofzo, dan sla je aardig de plank mis.

Dan sla ik de plank mis met de verkeerde gereedschap.

Ik vind mijn oplossing _redelijkerwijs_ genoeg voor de applicatie die ik bouw. Bovendien staat half internet, inclusief sommige grote gewaardeerde websites, vol met dezelfde voorbeelden (zelfs als je de zoekfilter instelt op 2019). Het enige is dat ik uit eigen initiatief zelf extra controle checks heb ingebouwd zowel als bij React als in mijn PHP backend.

Ik vind jouw reactie dat ik de verkeerde tool voor de job gebruikt dan ook een beetje raar maar ik snap je wel. Niet iedere developer werkt hetzelfde