Stig Christensen

RFC8941 - Structured Fields

Det viste sig at der faktisk var en koncentreret lille essens med en lille men utroligt ildelugtende bærme, primært bestående af "Set-Cookie" og "Cookie".

Mener du her, at cookie headeren var defineret på forskellige måder?

Jeg tænker, det er jo ofte en header, hvori man gemmer vilkårlig tekst, og så er det jo oplagt at bruge byte sekvensen.

Hvordan vil det gå med implementeringerne, bliver det bare hurtigt accepteret og udbredt?

9. februar 2021 kl. 21:07
Her er nyhederne i PHP 8: Parametre med navne og metadata

hvis implicit, ville du ødelægge rigtig meget eksiterende kode.

8. februar 2021 kl. 14:18
Vi tog fejl om læsefejl på floppyer

Om lidt er harddisken også gået i glemmebogen. De siger det samme, når de ikke kan læse. En gang lykkedes det mig alligvel, ved at lægge den i fryseren en halv time.

30. november 2020 kl. 12:48
Russisk hacker idømt syv års fængsel for stort angreb på LinkedIn og Dropbox

Ved hashing transformeres dit password til en <strong>næsten</strong> unik stump data

:)

6. oktober 2020 kl. 15:35
Måske skulle vi også droppe ordet computer..

Det bliver lidt trættende, at læse hvorfor stødende ord sagtens kan bruges, fra personer som ikke er fra samme befolkning. Den samme argumentation kunne bruges om ordet "neger" (det betyder sort), men her har de fleste lært det (og dog). Det handler vel om, at hvis tilpas mange ikke bryder sig om det, så lader man værre. Man behøver jo ikke at forstå alt, det handler jo om følelser og en lang kultur. Du argumenterer jo rent faktisk for at Inuitterne ikke tænker sig om.

5. august 2020 kl. 15:20
DMI har mistet 413.000 månedlige brugere: Hjemmeside får skylden

Jeg synes det er så morsomt, at de gamle grafer kan hentes via servlet.dmi.dk kald, og at bedrevejr.dk derfor kan lave en langt bedre oversigt. Hvorfor er det egenlig, at dmi stadigvæk tilbyder dem?

15. juli 2020 kl. 10:53
Sundhedsministeriet overvejer at åbne kildekoden til Smittestop-app

Men det er jo gratis, for den danske stat at bruge kildekoden, i stedet for at starte forfra. Så er det da lige meget, om nogen andre har betalt for at lave den.

9. juli 2020 kl. 13:56
Sundhedsministeriet overvejer at åbne kildekoden til Smittestop-app

Det er også gratis at køre på cykelstierne. Hvem har betalt dem?

Ok, 9 tommel ned og ikke en eneste op. Kan nogen forklare mig hvad det er jeg åbenbart har misset??

jeg har forsøgt at læse og forstå din kommentar med cykelstierne 2-3 gange, men kan ikke. Måske det er derfor?

9. juli 2020 kl. 10:24
Sundhedsministeriet overvejer at åbne kildekoden til Smittestop-app

Jeg forstår ikke helt hvad i vil bruge backend'en til i dette tilfælde. I kan jo se alt det data som App'en indsamler direkte på enheden ved blot, at decompile eller reverse engineer filen? Selve analysen af data i backend'en har jo ikke noget med sagen at gøre.

Det er vel kun i Backenden, du kan se om fx IP bliver logget og måske gemt uforsvarligt.

9. juli 2020 kl. 10:22
URL'ens historie: Hvis du ville logge på, skulle du oplyse passwordet som en del af URL’en

Jeg tror jeg nu giver op. Rendering kan sagtens bruges om HTML generering, søg lidt på nettet. Og det kan også bruge om den endelige skærmoptegning, selvfølgelig, og 3D og alt muligt andet. Men du vil kun forstå din egen verden. Husk at kigge indad.

Du kan lave øvelsen med notepad, du behøver slet ikke noget framework.

Tak for denne gang.

25. maj 2020 kl. 17:13
URL'ens historie: Hvis du ville logge på, skulle du oplyse passwordet som en del af URL’en

Øhh, nej, rendering foregår altid på klienten.

Du misforstår mig, når jeg her taler om rendering, så handler det om hvem som laver HTML strengen. Det sker klassisk på serveren, men kan også ske på klienten.

Et eller andet sted i processen skal der være en stringreplacment, således at anførselstegn konverteres til ogquotsemikolon, og tilbage igen den anden vej, hvem der så har ansvaret for den kan der være mange løsninger på - men det sker altså ikke på magisk vis.</p>
<p>Og selv om jeg så via et ajaxkald indsætter hele input linjen, feks. ved at bruge en divs id, eller tildeler value som du beskriver, så vil problematikken altså bestå, der må ikke forekomme et anførselstegn inde i en input value - der er nogle helt regelfaste krav til rendering af HTML, og dem kan vi altså ikke lave om på (og det er i bund og grund de regelfaste krav jeg mener man ikke har tænkt sig om med).

Jeg tror du må læse lidt om det, eller endnu bedre kode det selv. Der sker ikke nogen stringreplacement/encoding. Det er en DOM operation, i DOM træet er værdier ikke HTML encodet. Igen, sammenligningen med SQL parametre er 100% analog - her sendes teksten heller ikke med escapet apostroffer. Du har kun brug for encoding når du arbejder med HTML som en streng. Som tidligere beskrevet, så vil du oså opleve at "view source" slet ikke viser den HTML streng som du nok forventer at se.

25. maj 2020 kl. 13:13
URL'ens historie: Hvis du ville logge på, skulle du oplyse passwordet som en del af URL’en

Den må du gerne uddybe - hvad mener du med at HTML genereres på klienten?

De her frameworks kan jo virke på mange måder. Nogle sender blot en template (altså ikke HTML) som på klienten fortolkes via Javascript og renderes som HTML. Men HTML kan også renderes på serveren, og så skal klinten (igen via Javascript) blot sætte value på dine input felter. I begge udgaver finder du ingen streng-replacements.

  1. var str = ... streng fra et ajax kald;
  2. document.getElementById('myid').value = str;

25. maj 2020 kl. 10:26
URL'ens historie: Hvis du ville logge på, skulle du oplyse passwordet som en del af URL’en

(Du havde så lige lavet en lille fejl med mellemrummet før semikolonet, men lad det nu ligge)

Mange, mange tak. Det var ikke en fejl, men bevidst for at den ikke skulle fortolkes. Husk at kigge indad. :)

24. maj 2020 kl. 23:40
URL'ens historie: Hvis du ville logge på, skulle du oplyse passwordet som en del af URL’en

Og kan vi så ikke også blive enige om at "nogen" (mig, mit framework, eller julemanden) skal lave en stringreplacement før data gemmes i databasen?

Nej, vi er ikke enige. Hvis du bruger de rigtige abstraktioner/frameworks så sker dette aldrig (og det gør Baldur). Hverken når du skriver til databasen med parametre og når browseren sætter value via en DOM operation (jeg tror du misser at HTML genereres ude på klienten)

Hvis du arbejder direkte med SQL og HTML som strenge, ja så skal du huske at encode.

24. maj 2020 kl. 23:26
URL'ens historie: Hvis du ville logge på, skulle du oplyse passwordet som en del af URL’en

Kan du ikke bare svare på mit spørgsmål, hvordan vil indholdet af value se ud - det burde ikke være så svært at svare på!

Rolig nu, Baldur gør da et fantastisk arbejde med atr beskrive hvordan det hele hænger sammen.

Nu kender jeg ikke Scalatags, men pointen er vel at der ikke genereres statisk HTML med din tekststreng htmlencodet, som jo nok er det du søger.

[html] [/html]

HTML renderes sandsynligvis ud fra en template og vædier sættes via DOM operationer (det hele sker på klinten)

24. maj 2020 kl. 22:12
URL'ens historie: Hvis du ville logge på, skulle du oplyse passwordet som en del af URL’en

En tekststreng er jo en repræsentation af en bagvedliggende hexværdi (ascii), så der behøver jo sådan set ikke være en grafisk fremstilling af det - at det så kan være ganske praktisk er en anden sag, men så kunne man jo have opfundet nogle tegn som ikke konflikter med almindeligt skriftsprog.

Når det nu har været dit kæphest i mange år, og du aldrig ser det løst, så er det måske på tide at kigge ind af. :)

Du er nødt til at skelne mellem en visuel streng, som mennesker skal indtaste og læse fx en URL. Her skal vi kunne se separator-tegnet og samme sekund du har indført det, er der nogen som vil gemme det i en værdi (fx en url i en url). Prøv også at forestille de exploits der kunne ligge i en URL, hvis der er usynlige tegn?

Hvorfor tror du ikke at alle nyere programmeringssprog fikser din kæphest? Giv mig et sprog som ikke har escape-tegn til strenge.

Man kunne har gjort HTML til et binært format, som kun kunne genereres med et programmeringssprog/bibliotek. Det ville sikkert være gavnligt (ironi), men igen så flytter du blot det menneskevenlige præsentation og escapebehovet et led længere ud.

23. maj 2020 kl. 10:20
URL'ens historie: Hvis du ville logge på, skulle du oplyse passwordet som en del af URL’en

chr(29)

Det giver altså ikke helt mening, man skal jo kunne aflæse seperatortegnet i en URL, derfor skal der jo være et tegn som angiver det. Du vil måske skrive chr(29)? :) (som igen skal escapes hvis det indgår som streng i en værdi)

21. maj 2020 kl. 17:06
URL'ens historie: Hvis du ville logge på, skulle du oplyse passwordet som en del af URL’en

... og de her specieltegn, hvordan skulle man indtaste dem i sin kode? Eller hvordan skulle de optræde i en URL? De må jo være visuellle, og så pludselig en dag er der nogen som vil gemme disse specieltegn i en værdi og så skal du igen escape.

20. maj 2020 kl. 23:52
Er det altid godt at være dynamisk?

Jeg fortrækker statiske sprog, men er glad for dynamics i C# som man kan bruge hvor det giver mening.

Jeg kan slet ikke se hvordan jeg vil komme i mål med et dynamisk sprog, når man laver store refaktoreringer i store projekter. Her er compileren guld værd.

29. februar 2020 kl. 20:06