MijnOverheid Berichtenbox ondersteunt nu bestandsnamen tot 128 karakters
De Berichtenbox van MijnOverheid ondersteunt nu langere bestandsnamen tot 128 karakters. Eerder stond de limiet nog op 40 karakters. Dat laat Logius weten, de ict-dienstverlener van de overheid. Via de BerichtenBox van MijnOverheid kunnen burgers digitale post van de overheid ontvangen. Het gaat dan bijvoorbeeld om berichten van gemeenten, waterschappen, pensioenfondsen, ministeries, provincies, samenwerkingsverbanden en landelijke organisaties.
Inmiddels hebben meer dan 9,4 miljoen mensen een MijnOverheid-account waar alleen al in april ruim 4,5 miljoen berichten naar zijn toegestuurd. Door de verhoging van het maximaal aantal karakters zijn er volgens Logius voor overheidsinstanties meer mogelijkheden om de naam van mee te sturen bijlages op te bouwen. Dit moet voor een betere herkenbaarheid van de bestandsnaam zorgen, zo laat de ict-dienstverlener weten.
Reacties (13)
Zozo, zomaar 88 karakters extra, wat hebben ze weer fantastisch en hard gewerkt daar bij Logius. Die bonus van dit jaar gaat wederom niet meer dan geheel terecht zijn.
Damm MS-DOS 8.3 kon dit ook in 1995 https://en.wikipedia.org/wiki/MS-DOS
Maar waarom dan nu naar 128 karakters. Want SMS kan al sinds 1992 160 karakters verwerken. https://en.wikipedia.org/wiki/SMS
Dus je zou haast zeggen, hebben ze nog spul in gebruik van voor 1990? Hoe moeilijk is het om een database veld groter te maken? Welk filesysteem kan niet meer dan 128 karakters voor een bestandsnaam hebben?
Vragen... vragen vragen... hoe veilig is mijn data daar nu echt...?
TheYOSH
Maar waarom dan nu naar 128 karakters. Want SMS kan al sinds 1992 160 karakters verwerken. https://en.wikipedia.org/wiki/SMS
Dus je zou haast zeggen, hebben ze nog spul in gebruik van voor 1990? Hoe moeilijk is het om een database veld groter te maken? Welk filesysteem kan niet meer dan 128 karakters voor een bestandsnaam hebben?
Vragen... vragen vragen... hoe veilig is mijn data daar nu echt...?
TheYOSH
Tot en met 127 karakters gok ik? Een signed char in de programmeertaal C loopt van -128 tot 127. Dit kan problemen opleveren in een FOR loop omdat de loop niet stopt bij 127, maar dan -128 wordt waardoor de conditie om door te gaan met de loop nog steeds geldt (kleiner of gelijk aan 127, want -127). Deze FOR loop stopt dus nooit.
Verder heb je het probleem met Unicode. Waarbij een karakter 2 of zelfs 4 bytes groot kan zijn. Het is dus goed opletten voor de programmeurs met deze ontwerp keuze. Een slechte keuze dus.
Verder heb je het probleem met Unicode. Waarbij een karakter 2 of zelfs 4 bytes groot kan zijn. Het is dus goed opletten voor de programmeurs met deze ontwerp keuze. Een slechte keuze dus.
for(i=0; i<=127; i++)
{
}
{
}
Door Anoniem:
Welk filesysteem kan niet meer dan 128 karakters voor een bestandsnaam hebben?
Welk filesysteem kan niet meer dan 128 karakters voor een bestandsnaam hebben?
De meeste bestandssystemen ondersteunen enkel bestandsnamen tot 255 bytes: https://en.wikipedia.org/wiki/Comparison_of_file_systems
Doet me denken aan een grote machinebouwer in het zuiden des lands, over de grootte van arrays om tekst in op te slaan. Als de array-grootte 128 is, mogen er dan 128 karakters in (met zonder NULL) of maar 127? Uiteraard deed iedereen dit op een andere manier, ook met verschillende benamingen voor #defines zoals XXX_SIZE en XXX_LEN, en moet je dan malloc(XXX_SIZE+1) doen of juist niet?
Door Anoniem: Tot en met 127 karakters gok ik? Een signed char in de programmeertaal C loopt van -128 tot 127. Dit kan problemen opleveren in een FOR loop omdat de loop niet stopt bij 127, maar dan -128 wordt waardoor de conditie om door te gaan met de loop nog steeds geldt (kleiner of gelijk aan 127, want -127). Deze FOR loop stopt dus nooit.
Verder heb je het probleem met Unicode. Waarbij een karakter 2 of zelfs 4 bytes groot kan zijn. Het is dus goed opletten voor de programmeurs met deze ontwerp keuze. Een slechte keuze dus.
Het is XML, dus 128 karakters. Dus geen bytes. Dus in totaal 512 bytes max. En wie programmeert nog loops met integers als een unsigned char?Verder heb je het probleem met Unicode. Waarbij een karakter 2 of zelfs 4 bytes groot kan zijn. Het is dus goed opletten voor de programmeurs met deze ontwerp keuze. Een slechte keuze dus.
for(i=0; i<=127; i++)
{
}
{
}
Door Anoniem:
Door Anoniem: Tot en met 127 karakters gok ik? Een signed char in de programmeertaal C loopt van -128 tot 127. Dit kan problemen opleveren in een FOR loop omdat de loop niet stopt bij 127, maar dan -128 wordt waardoor de conditie om door te gaan met de loop nog steeds geldt (kleiner of gelijk aan 127, want -127). Deze FOR loop stopt dus nooit.
Verder heb je het probleem met Unicode. Waarbij een karakter 2 of zelfs 4 bytes groot kan zijn. Het is dus goed opletten voor de programmeurs met deze ontwerp keuze. Een slechte keuze dus.
Het is XML, dus 128 karakters. Dus geen bytes. Dus in totaal 512 bytes max. En wie programmeert nog loops met integers als een unsigned char?Verder heb je het probleem met Unicode. Waarbij een karakter 2 of zelfs 4 bytes groot kan zijn. Het is dus goed opletten voor de programmeurs met deze ontwerp keuze. Een slechte keuze dus.
for(i=0; i<=127; i++)
{
}
{
}
De 8 bitters uit begin jaren ‘i80?
19-05-2022, 16:15 door
majortom
Door Anoniem:
Ik neem aan dat je een signed char bedoeld: die loopt van -128 tot 127; een unsigned char loopt van 0 t/m 255 en dan heb je dit "probleem" niet.Door Anoniem: Tot en met 127 karakters gok ik? Een signed char in de programmeertaal C loopt van -128 tot 127. Dit kan problemen opleveren in een FOR loop omdat de loop niet stopt bij 127, maar dan -128 wordt waardoor de conditie om door te gaan met de loop nog steeds geldt (kleiner of gelijk aan 127, want -127). Deze FOR loop stopt dus nooit.
Verder heb je het probleem met Unicode. Waarbij een karakter 2 of zelfs 4 bytes groot kan zijn. Het is dus goed opletten voor de programmeurs met deze ontwerp keuze. Een slechte keuze dus.
Het is XML, dus 128 karakters. Dus geen bytes. Dus in totaal 512 bytes max. En wie programmeert nog loops met integers als een unsigned char?Verder heb je het probleem met Unicode. Waarbij een karakter 2 of zelfs 4 bytes groot kan zijn. Het is dus goed opletten voor de programmeurs met deze ontwerp keuze. Een slechte keuze dus.
for(i=0; i<=127; i++)
{
}
{
}
Door Anoniem: Damm MS-DOS 8.3 kon dit ook in 1995 https://en.wikipedia.org/wiki/MS-DOS
Maar waarom dan nu naar 128 karakters. Want SMS kan al sinds 1992 160 karakters verwerken. https://en.wikipedia.org/wiki/SMS
Dus je zou haast zeggen, hebben ze nog spul in gebruik van voor 1990? Hoe moeilijk is het om een database veld groter te maken? Welk filesysteem kan niet meer dan 128 karakters voor een bestandsnaam hebben?
Vragen... vragen vragen... hoe veilig is mijn data daar nu echt...?
TheYOSH
Maar waarom dan nu naar 128 karakters. Want SMS kan al sinds 1992 160 karakters verwerken. https://en.wikipedia.org/wiki/SMS
Dus je zou haast zeggen, hebben ze nog spul in gebruik van voor 1990? Hoe moeilijk is het om een database veld groter te maken? Welk filesysteem kan niet meer dan 128 karakters voor een bestandsnaam hebben?
Vragen... vragen vragen... hoe veilig is mijn data daar nu echt...?
TheYOSH
De antwoorden op "hoe moeilijk is het om .... " komen meestal als je echte werkervaring hebt in een landschap waarin veel systemen staan , een lange historie , en veel dependencies .
Dan leer je dat "update veldlengte in database table" zelden of nooit het probleem is - maar het testen en valideren van een heel grote keten van systemen die dat soort aannames ingebouwd hebben _wel_ .
Wie meeleest met Linux kernel development heeft over pakweg het afgelopen _decennium_ kunnen volgen "hoe moeilijk het is om tijd naar 64 bit te brengen" .
Door Anoniem: Zozo, zomaar 88 karakters extra, wat hebben ze weer fantastisch en hard gewerkt daar bij Logius. Die bonus van dit jaar gaat wederom niet meer dan geheel terecht zijn.
Jammer deze kortzichtigheid. Er zijn allerlei redenen waarom systemen dit soort beperkingen kennen.
En als deze vervolgens worden opgerekt of er uit worden gehaald krijg je natuurlijk weer dat mensen klagen dat ze fouten krijgen bij het downloaden en openen van bestanden met te lange namen, dus dat moet ook worden getest en ondervangen.
Logius zal niet perfect zijn en er worden vast flink wat publieke middelen aan besteed om de diensten te ontwikkelen en onderhouden, maar als je het vergelijkt met de landen om ons heen dan doen we het hier best heel goed.
Door Anoniem:
De meeste bestandssystemen ondersteunen enkel bestandsnamen tot 255 bytes: https://en.wikipedia.org/wiki/Comparison_of_file_systems
Door Anoniem:
Welk filesysteem kan niet meer dan 128 karakters voor een bestandsnaam hebben?
Welk filesysteem kan niet meer dan 128 karakters voor een bestandsnaam hebben?
De meeste bestandssystemen ondersteunen enkel bestandsnamen tot 255 bytes: https://en.wikipedia.org/wiki/Comparison_of_file_systems
Je mag toch hopen dat Logius de bestanden niet echt opslaat onder de naam die die gebruiker geeft, maar dat dit alleen
een veld in een database is, en dat als de file ergens in een filesystem wordt opgeslagen dit gebeurt met een door
het systeem zelf gegenereerde unieke naam (die veel korter kan zijn) en waar de database dan weer naar verwijst?
Files opslaan in een filesystem met door een remote gebruiker opgegeven naam dat lijkt me een recept voor problemen.
Wat als gebruikers het voor elkaar krijgen om namen voorbij de naamcontrole te krijgen die verderop in het systeem
toch ineens problemen geven? We kennen allemaal wel de problemen in webservers door het incorrect verwerken
van namen met ../.. erin, dat moet je gewoon niet willen.
Daarmee wordt het hele "beperking van filesystem" argument nutteloos en gaat het dus alleen nog om veldlengtes.
@11:54
Je moet bestandsnamen toelaten die onder alle gangbare file systemen geaccepteerd worden. Als je een bestand (bijvoorbeeld een .pdf) ontvangt in je berichtenbox, moet je dat ook eerst op je eigen harde schijf planten voor je het openen kan.
Ik herinner me dat in Xubuntu een teken zat in elk screenshot (dubbel punt of zo), waar Windows Vista niet mee om kon gaan. Dat is dus hoe het niet moet.
Je moet bestandsnamen toelaten die onder alle gangbare file systemen geaccepteerd worden. Als je een bestand (bijvoorbeeld een .pdf) ontvangt in je berichtenbox, moet je dat ook eerst op je eigen harde schijf planten voor je het openen kan.
Ik herinner me dat in Xubuntu een teken zat in elk screenshot (dubbel punt of zo), waar Windows Vista niet mee om kon gaan. Dat is dus hoe het niet moet.
Door Anoniem:
Je mag toch hopen dat Logius de bestanden niet echt opslaat onder de naam die die gebruiker geeft, maar dat dit alleen
een veld in een database is, en dat als de file ergens in een filesystem wordt opgeslagen dit gebeurt met een door
het systeem zelf gegenereerde unieke naam (die veel korter kan zijn) en waar de database dan weer naar verwijst?
Files opslaan in een filesystem met door een remote gebruiker opgegeven naam dat lijkt me een recept voor problemen.
Wat als gebruikers het voor elkaar krijgen om namen voorbij de naamcontrole te krijgen die verderop in het systeem
toch ineens problemen geven? We kennen allemaal wel de problemen in webservers door het incorrect verwerken
van namen met ../.. erin, dat moet je gewoon niet willen.
Daarmee wordt het hele "beperking van filesystem" argument nutteloos en gaat het dus alleen nog om veldlengtes.
Door Anoniem:
De meeste bestandssystemen ondersteunen enkel bestandsnamen tot 255 bytes: https://en.wikipedia.org/wiki/Comparison_of_file_systems
Door Anoniem:
Welk filesysteem kan niet meer dan 128 karakters voor een bestandsnaam hebben?
Welk filesysteem kan niet meer dan 128 karakters voor een bestandsnaam hebben?
De meeste bestandssystemen ondersteunen enkel bestandsnamen tot 255 bytes: https://en.wikipedia.org/wiki/Comparison_of_file_systems
Je mag toch hopen dat Logius de bestanden niet echt opslaat onder de naam die die gebruiker geeft, maar dat dit alleen
een veld in een database is, en dat als de file ergens in een filesystem wordt opgeslagen dit gebeurt met een door
het systeem zelf gegenereerde unieke naam (die veel korter kan zijn) en waar de database dan weer naar verwijst?
Files opslaan in een filesystem met door een remote gebruiker opgegeven naam dat lijkt me een recept voor problemen.
Wat als gebruikers het voor elkaar krijgen om namen voorbij de naamcontrole te krijgen die verderop in het systeem
toch ineens problemen geven? We kennen allemaal wel de problemen in webservers door het incorrect verwerken
van namen met ../.. erin, dat moet je gewoon niet willen.
Daarmee wordt het hele "beperking van filesystem" argument nutteloos en gaat het dus alleen nog om veldlengtes.
Niet alleen security zoals directory traversal , en "verboden karaketers".
Bedenk ook hoeveel problemen er op de loer liggen vanwege duplicate namen - "vergunning_aanvraag.pdf" , dat zal er vast maar ééntje zijn. Net als : "Re antwoord"
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
