Discussion :

[petitcoucou31]

bonjour a tous ..( je renouvelle ce post car je le trouve plus ! )

je voudrais savoir si il existe une zone dans un fichier texte ou je puisse ecrire un octet , sans que c'est octet soit visible par un editeur de texte standart ( style notepad ) ou recopiable via le presse papier .

le but de ma manip est d'identifier le type de fichier texte pour donner certain droit a l'utilisateur ( ce qui est fait) .

Le stockage des droits doit etre stocké dans son propre fichier car ils peuvent etre deplacer de machine en machine , voir de societé en société .

mais a ce jour les droit peuvent etre modifié par un quelconque editeur de texte . d'ou le besoin d'ecrire des info invibles ( par exemple l'endroit ou son stocké les info du fichier date de creation .... )

merci pour tous , je suis preneur de toute les idées .

[Aloneghost]

bonsoir Je suis trés loin d'etre doué en ce qui concerne delphi, mais ne serait t'il pas plus pratique dans ton cas de créer des fichier d'enregistrement record portant une extention que tu choisirais qui accompagneraient ton fichier texte, voir de crypter le texte dans un fichier spécial, que tu devrais décripter ou pas selon que la personne possede l'acréditation ou pas. Il te "suffirait" dans ce cas, de décrypter tes données et de le remetre sous forme de texte avant de les affichher... j'espere que je ne dis pas de betises...

[petitcoucou31]

salut non tu ne dis pas de betises !

j'aurai pu en effet mettre les droit dans un autre fichier ( premiere option que j'avais envisager ) ,mais le client ne veut pas de fichier
supplementaire,... les mettres dans la base des registres , mais le fichier se promene de machine en machine donc pas possible non plus .

j'ai ensuite crypté mon fichier pour qu'il ne puisse retrouver les droit a l'interieur , mais les parties utiles doivent rester lisible , donc on connait la zone ou se trouve les droit .


en fait le but de l'operation est la suivante :

Faire en sorte de bloquer l'utilisation d'un fichier texte par l'application si il a subit une modification et si ces droit ne le lui permettait pas .
donc 3 cas se presente
- ancien fichier ( pas de droit )
- nouveau fichier avec possibilité de modification
- nouveau fichier sans possibilité de modification

et dans les 3 cas ces fichiers doivent rester lisible par un editeur de texte exterieur a l'application.

donc une simple info me permettrai de savoir de quel type de fichier il s'agit , mais elle doit pas etre visible.

si d'autre idée vous passe par la tete je susi prenneur.

[Graffito]

Bonjour,

On pourrait penser qu'un EOF (DTL-Z) en fin de fichier suivi des données à cacher aurait pu marcher, mais ce n'est pas le cas.

Si le seul but est d'empêcher la modification de certaines données, pourquoi ne pas insérer un checksum calculé sur les les droits (algorithme non publié) et le vérifier à l'utilisation : si un utilisateur modifie les droits, le checksum ne sera plus bon.

[Laurent Dardenne]

Et en réfléchissant bien on te demande de faire qq chose qui n'est pas possible. Il y a des données et des droits et je ne connais pas d'OS qui regroupe nativement ces 2 informations dans un même conteneur ( mais je ne connais pas tout non plus ).

Qq pistes :
Je pensais aux fichiers composites OLE mais il se peut qu'ils nécessitent un lecteur spécifique.
MS Office 2003 à instaurer une politique de sécurisation des documents (IRM), je n'ai pas creusé le sujet mais il se peut qu'il se base sur ce principe.

Il y a les Flux mais il ne sont pas copiés avec les API de base.

Il existe la signature de code, c'est le principe mis en place sous Monad ou WSH pour se protéger de la modification d'un script, mais dans ce cas la signature apparait dans le fichier :-(.

[edit]
Ton titre ne correspond pas du tout à ton pb, tu ne te facilites pas la tâche :-)

[petitcoucou31]

Oui Laurent , a mon avis aussi un truc pas trop possible normalement, d'ou la recherche d'une maniere detourné !

Graffito, j'essaye aussi les checksums !

En fait je calcule la cheksum de mon fichier et j'inserre a l'interieur des valeur hexa qui corresponde a mes droits , ils deviennent donc illisibles et donc 'non modifiable' ( on touche pas a ce qu'on sait pas ! sous peine de ne plus pouvoir exploiter le fichier )

cela marche ... presque bien !!!

Sauf si un petit malin recopie la totalité de la checksum d'un fichier (avant des droit a la modification) dans un fichier (qui a pas les droit a la modification ) .

Dans ce cas çà change les droits et donc je controle plus la checksum puisque j'autorise la modification.

il me reste plus qu'a detecter que la ligne de checksum appartiens pas au fichier ( une autre checksun ???? ).
pour cette nouvelle checksum j'ai pensé aux dates de creation , modification ...du fichier , mais cela change aussi quand on change le fichier de volume !! donc je dois trouver autre chose (peut etre le nom du fichier si celui ci ne change jamais !!)

Merci pour vos idées .

[Graffito]

Bonjour,

Tu pourrais peut-être mettre le checksum dans la date de création du fichier. Cette date devrait rester inchangée en cas de modification.

[Laurent Dardenne]

Tu pourrais peut-être mettre le checksum dans la date de création du fichier. Cette date devrait rester inchangée en cas de modification.

Oui mais cette info est perdu lors d'une copie et cela fausserais des traitements de sauvegarde basés sur la date par exemple.

[Graffito]

Oui mais cette info (date de création) est perdu lors d'une copie et cela fausserais des traitements de sauvegarde basés sur la date par exemple

.

Exact, la copie modifie la date de création (j'aurais pas cru ).

[tourlourou]

vérifie si tu ne peux pas stocker dans les attributs du fichier : c'est un entier, mais tous les bits ne semblent pas utilisés par l'OS (à savoir s'ils sont recopiés ???)

[Aloneghost]

Une idée pas trés conventionnelle (J'ai l'esprit un peu tordu :p)
- lorsque ton application est en fonctionnement, tu gere deux "fichier" qui seront supprimé plus atrd... Dans le premier, les droits, dans le second, les donnée, lorsque tu sauvegarde ton fichier, tu crypte séparément les donnée, les rassemble selon un algo de ton cru qui permet la lecture des donnée incompréhenssible sur un éditeur de texte et tu sauvegarde le tout dans un unique fichier.

Lorsque ton application ouvrira le dit fichier, elle utilise donc un premier algo pour séparer les données, ensuite, ton appli décripte la partie "droit", si elle est corecte, tu décripte le reste, et tu permet des modifications, si elle ne l'est pas, tu interdit l'acces aux données... Ca te permetrait de gerer par la meme les modifications effectué avec les editeurs de texte comme des erreurs...

Ceci rend tes fichiers completement illisible par n'importe quel autre application...Si tu voulais que tes fichiers soient lisible apr n'importe quel éditeur, alors c'est une trés mauvsaise idée que je viens de t'exposer

NB: j'ai conscience que cette methode est trés brutale et peu conventionnelle, mais pour de spersonnes n'y connaissant pas grand chose en programmation, ca peut amplement suffire
(tappez moi si je dis une betise )

[ryko]

Bonjour,

j'avais lu dans la doc delphi que les fichiers étaient tous représentés avec un entête au format Record. Voici une copie de la doc en ligne de Delphi2. Ne pourrait-on pas utiliser la zone UserData pour stocker ce qu'on veut ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
Unité
SysUtils
Déclaration
PTextBuf = ^TTextBuf;
TTextBuf = array[0..127] of Char;
TTextRec = record
  Handle: Integer;
  Mode: Integer;
  BufSize: Cardinal;
  BufPos: Cardinal;
  BufEnd: Cardinal;
  BufPtr: PChar;
  OpenFunc: Pointer;
  InOutFunc: Pointer;
  FlushFunc: Pointer;
  CloseFunc: Pointer;
  UserData: array[1..32] of Byte;
  Name: array[0..259] of Char;
  Buffer: TTextBuf;
end;

Description
TTextRec est le format interne d'une variable de type texte. Vous ne déclarez jamais une variable de ce type. Toutefois, vous pouvez utiliser TTextRec pour transtyper une variable fichier texte afin d'accéder à ses champs internes, au nom du fichier par exemple.
Remarque : N'utilisez ce type que si vous avez une bonne maîtrise de l'écriture des pilotes de périphérique de fichier texte en Pascal Objet.

Il y a aussi le type TFileRec :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
TFileRec = record
  Handle: Integer;
  Mode: Integer;
  RecSize: Cardinal;
  Private: array[1..28] of Byte;
  UserData: array[1..32] of Byte;
  Name: array[0..259] of Char;
end;

Description
TFileRec est le format interne pour les fichiers typés et non typés. TFileRec vous permet de transtyper une variable fichier pour accéder à ses champs internes.
Remarque : Normalement, vous ne devriez jamais déclarer une variable de ce type.

[petitcoucou31]

Merci pour toutes vos idées .. !

Mais la seule solution pour ce que je voulais faire ( dans son integralité ) , aurait été d'avoir un attribut de lecture seule qui ne soit pas modifiable depuis windows et que je puisse gerer a ma convenance puisque ce fichier peut dans certain cas etre editable ( et cet attribut n'existe pas !! ).

Donc a ce jour la seule chose que je fais, c'est de detecter une modification du fichier avec un jeu de checkum .
Dans le cas où la modification est interdite , j'imprime un filigramme sur le document pour indiquer que le document a subit une modification avec un application autre que celle qui crée le fichier .

bye a tous ! ( sujet a creuser quand meme !! )