Subiecte

Se pot descărca de aici

http://www.webgest.ro/websign/SignDoc.html

variantele de aplicație desktop (deocamdată applet-ul nu-i funcțional).

Se face automat semnarea unui fișier pdf, cât și semnarea mail-ului. Sperăm să se înțeleagă setarea parametrilor.

Semnătura electronică, sau digitală, este echivalentul semnăturii clasice, olografe ce se aplică pe hârtie, de data aceasta fiind vorba de aplicarea asupra unui document în format electronic. Semnătura însăși este un document electronic, ce poate fi integrat (vizual sau nu) în documentul semnat sau poate rămâne o entitate separată de acesta. Ea trebuie să asigure trei elemente doveditoare asupra documentului semnat:
- autenticitatea -  semnatarul este cel care a generat/semnat documentul.
- integritatea – conținutul documentului nu a fost modificat după momentul semnării.
- nonrepudierea – semnatarul nu poate nega faptul că el a semnat documentul.

Semnătura rezultă în urma aplicării asupra conținutului documentului a unui algoritm de criptare, pe baza unei chei private care-l identifică pe posesor, și constă întrun șir de caractere generat în funcție de conținutul din acel moment. Orice modificare ulterioară a documentului determină o invalidare a semnăturii. Validitatea se verifică cu ajutorul cheii publice, pusă la dispoziție de semnatar, împreună cu un certificat digital care atestă identitatea semnatarului și faptul că el este autorizat de o organizație de încredere – CA (Certificate Authority).

Respectând anumite standarde de utilizare și de păstrare a cheii private, semnătura digitală poate fi chiar mai sigură decât cea clasică. Prin tendința firească de dematerializare a documentelor, prin renunțarea tot mai mult la hârtii, importanța ei crește. Lucrurile vor fi și mai evidente pe măsură ce se vor adopta structuri standard pentru documente, care să poată fi prelucrate automat de calculator, atât la   generare cât și la primire, fără intervenție umană. Avantajele ar trebui să fie văzute atât de mediul   bussines, cât și de administrație sau cetățean. Va fi cu adevărat era digitală... Deocamdată, încă se pune accent pe forma vizuală a documentelor (pdf, pdf/A – pdf arhivabil) și mai puțin pe formatul de date interoperabile (care pot fi la fel de bine semnate și protejate).

Un certificat digital reprezintă dovada, din partea unei autorități superioare, că posesorul său este cel ce se pretinde a fi. Formatul de bază al unui certificat este reprezentat de standardul X.509, care stipulează setul de elemente ce trebuie conținut de certificat: titular, data generării, perioada de valabilitate, autoritatea emitentă etc. Alături de aceste date, care sunt publice, în (sau lângă) certificat se regăsește și cheia publică a titularului, cea care este perechea cheii private a acestuia (cele două se generează simultan). Cheia privată are un regim strict de securitate și se depozitează în locuri protejate.

Sunt două modalități de păstrare a certificatelor, stabilite prin standardele criptografice PKCS (Public-Key Cryptography Standards) publicate de RSA Security:

PKCS#12 – în fișiere, de tip .p12 - fiind urmașul vechiului .pfx (Personal Information Exchange Syntax)
PKCS#11 – în dispozitive hardware inteligente - smartcarduri

Standardul în care se păstrează semnătura electronică, sau fișierul semnat, este PKCS#7.

Certificatele au un regim special de păstrare și manipulare pe un calculator, diferit de fișierele obișnuite. Un certificat păstrat pe smartcard, eliberat de o autoritate competentă, care la rândul ei este  autorizată de o CA superioară, într-un "lanț de încredere", se numește certificat digital calificat. Specific acestor dispozitive este faptul că cheia privată nu se poate copia și nu poate părăsi dispozitivul, nici chiar în momentul semnării. Comunicarea dintre un calculator și un smartcard se face conform standardului PKCS#11, prin librării specifice sistemelor de operare și limbajelor de programare utilizate. La cel mai jos nivel interacțiunea poate fi diferită, în funcție de producător, unele dispozitive funcțiomând cu drivere generice, altele necesitând drivere specifice. Comunicarea se desfășoară la fel, indiferent de forma în care este ambalat chipul - token usb sau card, ce necesită un cititor.

Utilizarea certificatelor (cele hard) este foarte largă, nu doar pentru semnare de documente: de la logarea în sistem sau în unele aplicații, la navigarea web sau trimiterea de mail. Și este o practică veche sub Linux. Problema o reprezintă aici nu lucrurile standard ci, ca de obicei, implementările particulare ale unor producători. Multe din cititoarele, smartcardurile sau USB-Token-urile produse sunt recunoscute automat în Linux și manageriate de daemonul pcsc.

Pentru celelalte însă sunt necesare drivere de la producători. Este cazul și al tokenurilor pe care se distribuie acum certificatele calificate de către firmele autorizate în România. Dacă vreți să folosiți un astfel de dispozitiv sub Linux, insistați la achiziționare să vi se pună la dispoziție și drivere specifice. Cel puțin deocamdată, pe viitor fiind șanse să fie cuprinse și acestea în lista proiectului OpenSC (bine-ar pica și puțină participare românească...).

Experiența personală a avut loc cu două tipuri de dispozitive de tip smartcard USB token: Oberthur ID One Cosmo 64 și Aladdin eToken 64 Pro. Cu primul n-am avut succes, deocamdată. Cu toate că producătorul se laudă în unele prezentări că pune la dispoziție drivere și un soft de management – AWP (Authentic Web Pack) – disponibil pentru toate sistemele de operare importante (Windows, Mac, Linux), n-am reușit să ajung în posesia versiunii de Linux, cea care ne interesa. Din păcate nu sunt prinse driverele, pentru acest model,  nici în OpenSC sau CCID (care sunt incluse în majoritatea distribuțiilor actuale de Linux). Din acest punct de vedere, la fel se petrec lucrurile și cu celălalt model, de la Aladdin. La acesta însă se găsește pachetul complet de instalare de la producător: eToken PKI Client.

Instalarea și folosirea lui nu ridică probleme unui utilizator obișnuit de Linux. Pachetul conține și documentația necesară, care e și suficientă. Pe distribuțiile mai noi (am făcut probe pe ultilele versiuni de Fedora) totul se poate reduce la câteva clicuri, dacă nu ești un nostalgic al terminalului sau un maniac al controlului propriului sistem. Se instalează un serviciu propriu și un executabil cu interfață grafică (eToken) pentru administrare.

Installer-ul pune la locul lor toate librăriile necesare. Esențial pentru comunicarea cu dispozitivul hardware este acel shared object (.so), echivalentul dll-ului pentru Windows, în cazul nostru (Aladdin eTocken și Fedora/RedHat) fiind vorba de libeTPkcs11.so, localizat în /usr/lib sau /usr/lib64, în funcție de versiunea 32 sau 64 biți. Important: pentru compatibilitate, Firefox sau Thunderbird trebuie să fie pe aceeași versiune cu .so-ul – nu funcționează Firefox pe 64 biți cu .so-ul pe 32, sau invers.

O primă probă de funcționalitate a driverului se poate face tocmai întruna din aceste aplicații, Firefox sau Thunderbird. Modalitatea este descrisă complet în documentația venită în pachet sau pe paginile distribuitorilor. Din momentul în care se Load-ează corect modulul – în  Thunderbird / Edit / Preferences / Advanced / Certificates / Security Devices / Load, alegând locația potrivită pentru so (/usr/lib/libeTPkcs11.so sau /usr/lib64/libeTPkcs11.so) și ați putut intra în Log In (din aceeași pagină, cu parola tokenului) – o să apară certificatul nou în Thunderbird / Edit / Preferences / Advanced / Certificates / Views Certificates / Your Certificates . Din  Thunderbird îl și puteți folosi la semnat mesaje trimise.

Folosirea tokenului, sau în general a certificatelor depozitate pe smartcard – PKCS#11 -, în alte aplicații poate fi diferită față de cea din produsele Mozilla (Firefox și Thunderbird). Unele dintre acestea, gen Open Office, se folosesc automat de modulele încărcate în Mozilla (prioritar de cele din  Thunderbird). Altele, gen Adobe Acrobat Reader, permit din propriile setări încărcarea .so-ului, direct din lib-ul sistemului de operare.

Aplicații specifice pot folosi API-urile limbajului de programare în care sunt scrise. Pentru Java există pachete standard ce se ocupă de smartcard și PKCS#11 incluse în JRE (Java Runtime Environment), mașina virtuală ce îndeobște se instalează default pe majoritatea sistemelor de operare. Aplicațiile scrise în Java au avantajul, pe lângă faptul că sunt portabile – rulează la fel pe orice mașină/sistem de operare -, utilizării unor standarde de performanță și securitate.

Versiunile mai noi de Acrobat Reader (peste 9) funcționează corect și pe Linux, inclusiv partea de semnătură electronică. Fișierul semnat rezultat trebuie să fie identic cu cel semnat sub Windows, și să fie acceptat de instituțiile care cer tot felul de documente (declarații) în acest format.

Pentru a folosi certificatele digitale la semnare, e necesară înainte adăugarea lor în Document/SecuritySettings/DigitalIDs. În form-ul Add Digital ID se pot adăuga atât certificate din fișiere (.p12 sau .pfx = PKCS#12) – alegând "A file" -, cât și de pe dispozitive hardware (PKCS#11) – alegând "A device connected to this computer" -, arătând locația fișierului .so ( libeTPkcs11.so în cazul Aladdin). În momentul acțiunii de semnare se poate alege certificatul dorit.

Am creat un mic program, deocamdată demonstrativ, cu ajutorul căruia se pot semna fișiere PDF, urmând și alte tipuri, în special XML. Poate fi descărcat de la http://webgest.ro/download/websign.zip , sau http://webgest.ro/download/websignplus.zip - varianta ce conține și librăriile suplimentare.

Pagina cu o scurtă descriere este la http://webgest.intelx.ro:8080/webgest/util/SignDoc.jsp ( sau la http://www.webgest.ro/websign/SignDoc.html ).

Un capitol interesant al utilizării certificatelor digitale și a semnăturii electronice îl reprezintă aplicațiile web. Pe lângă problemele speciale de securitate legate de manipularea cheii private - ce trebuiesc rezolvate și întro aplicație desktop, care rulează local -, se ridică noi probleme, generate de protocoalele de comunicare. Soluția pentru aceste cazuri vine tot de la Java și se cheamă Java Applet.

Un applet este o mini aplicație ce se încarcă în pagina web (de pe server) dar care rulează pe sistemul local al clientului, folosind mașina virtuală (JRE) a acestuia. Legătura dintre browser și java se realizează printrun plugin, ce trebuie instalat asemănător altora, ca de pildă a celui de flash. Appletul are drepturi limitate de acces la nivel de sistem de operare local, spre deosebire de o aplicație desktop. În cazul folosirii unui applet pentru acces la un certificat local, precum și la un fișier local pentru a fi semnat, trebuiesc date drepturi explicite pentru aceste operațiuni de către utilizatorul sistemului. În afara accesului la aceste fișiere, și eventual la un loc unde să fie scrise fișierele semnate, appletul nu poate provoca "alte pagube". Inconvenientul setării unor astfel de drepturi, eventual prin scrierea lor întrun fișier de configurare, rămâne singurul în cazul unor aplicații web și este îndeajuns compensat de avantaje.

Un demo la http://webgest.intelx.ro:8080/webgest/util/SignDoc.jsp sau la http://www.webgest.ro/websign/SignDoc.html

Urmează implementarea la documentele principale, facturi și contracte. Și integrarea în procesul de trimitere mail.

Versiunea 4 beta s-a dovedit destul de stabilă. Cu mici modificări/corecții s-a lansat 4.0.0 .

Am sărit, până la urmă, peste versiunea anunțată a urma: 3.3 . Am făcut, pe lângă modificările în structura bazei de date, și ceva modificări legate de tehnologie, așa că am trecut la versiunea cu prefixul 4. Deocamdată, beta.

Până la versiunea 3.3, s-au făcut unele modificări/corecții mai urgente.

Definitivare PVMP.

Corecție tipărire recepție amănunt (legat de tva4428).

Corecție căutare documente furnizori/clienți (pentru cazul că partenerul este și client și furnizor).

Modificare tipărire și salvare documente din aplicație (PDF in loc de postscript).

Modificare tipărire balanță cu 5 egalități în format landscape (cu explicație cont).

Modificare la afișare vizitatori din Setup.jsp.


Urmează versiunea 3.3, cu modificări în baza de date legate de serii, loturi, termene de garanție...

Definitivare rapoarte custodie furnizori (registru custodie).

Centralizator vănzări articole - posibilitate scoatere detaliat sau cumulat pe articole.

Corecții la afișare recepție (diferențe din rotunjiri).

Implementare (parțială) pentru limitare permisiuni operator.

Afișare detalii contract la factura emisă.

Modificare PVMP (proces verbal modificare preț), legat și de schimbarea procentului de tva.

Principala rezolvare o reprezintă custodia dela furnizori. Mai sunt de făcut niște rapoarte, legat de aceasta, ș-apoi și celelalte tipuri de custodii: dela client, la furnizor și la client.

Urmează extinderea posibilităților de administrare a drepturilor de acces ale operatorilor.

Permiterea modificării simbolului pentru gestiune.

Păstrarea siglei la refacere date.

Corecție la preluare note contabile salarii.

Corecție la inițializare solduri balanță ( pe luna ianuarie ).

Corecție la centralizatoarele de casă/bancă ( pentru cazul în care nu există nicio zi închisă ).

Modificare închidere lună (optimizare pentru factrest, în cazul datelor f.multe).

Modificare atenționare de așteptare (la unele operații).

Corecție stornare la factura emisă și afișare nr.bon consum/transfer.

Pentru următoarea versiune Webgest (3.3) pregătim modificări în structura bazei de date. Printre altele vor apare câteva câmpuri noi legate și de factură-recepție, la nivel de articol (serie, cod producător, etc).

Încercăm să prindem toate acestea și întrun format standard, cât mai larg acceptat, de factura.xml pe care să-l cuprindem în registrul XDOC.

Vă rugăm să aduceți adăugiri și comentarii - câmpuri ce le întâlniți în practică sau doar ar fi utile de acum înainte.

Pe baza acestei structuri vom încerca să facem posibilă preluarea automată a datelor la recepție, dintrun document care respectă acest standard.

Modificare ofertă clienți.

Corecție script Corecții istbalantă, din Setup (apărea eroare în unele cazuri).

Corecții afișare ultima versiune (pentru sesiune expirată).


Am pus și o versiune nouă a aplicației WebSal ( http://www.xdoc.webgest.ro/ ), care a mai avansat și poate fi deja folosită "în producție" pentru cazuri mai simple.

Preluare automată plăți salarii din note contabile de tip NCSALBASS, la extras bancă.

Corecții la import note contabile salarii-după modificare structură fișier de preluat.

Posibilitatea corectării de note contabile manuale dintro lună închisă.

Modificări la declarația 300 (necesită pluginul de xforms în browser).

Corecții la raportul Impozit+TVA.

Corecție chitanță pdf-citire siglă din baza de date.

Corecție bon consum pdf-adaugare total,etc.

Modificare afișare ultima versiune în pagina de pornire a aplicației.

Corecții la detaliere note contabile.

Corecții la închidere lună-continuitate id-uri.

Adăugare informații despre ultima balanță finalizată.

ATENȚIE!!! Trebuie rulat din Setup.jsp scriptul 'Corectii istbalanta'

[Personal/Salarii]

Personal/Salarii

Loc de discuții despre domeniu și în special despre WEBSAL, un proiect pornit în paralel cu WEBGEST, pe o tehnologie cu totul nouă - XForms - și cu marea contribuție a lui @vios. De văzut la:

http://www.xdoc.webgest.ro/#

XDOC

Am pornit un fel de registru - de găsit tot la link-ul de mai sus - în care încercăm să cuprindem standarde de documente, în principal descrise prin XML Schema. Aceasta ar fi o contribuție la ceea ce se cheamă interoperabilitate - preluarea automată a datelor/documentelor, indiferent cu ce aplicație sunt generate. De aici importanța standardizării acestor formate.

Modificare bon consum (se permite consum marfă din gestiune depozit).

Corecție Jurnal vânzări/cont și Jurnal cumpărări/cont, varianta grafică (să încapă în pagină).

Modificare centralizator vânzări (să apară si adaosul).

Posibilitatea adăugării unui partener extern, cu atribut fiscal specific.

Corecție balanță în format pdf (din istoric sau din anul curent).

Corecție închidere lună (legat de trecere balanță în istoric).

ATENȚIE!!! Unele rapoarte din aplicație s-au realizat/modificat cu o nouă versiune de BIRT. Pentru a rula corect, pe un sistem funcțional, trebuie făcute următoarele:

- Se editeaza fisierul catalina.properties din Tomcat/conf pentru a defini locațiile în care se afla librăriile proprii aplicatiei. Se completeaza linia "shared.loader=" cu "${catalina.home}/lib/wglib,${catalina.home}/lib/wglib/*.jar,${catalina.home}/webapps/ReportEngine/lib,${catalina.home}/webapps/ReportEngine/lib/*.jar".

- Se șterg vechile librării ce aparțin de BIRT (care încep cu X-BIRT...) din Tomcat/lib.

- Se instaleaza noua versiune de BIRT (vezi pagina de instalare, partea A.Instalare manuala).

La un sistem instalat recent, cu versiunea nouă de BIRT, nu sunt necesare aceste modificări.