Intrebari generale

Re: proceduri stocate in SQL Server 2005

Gherry — Thu, 07 Aug 2008 20:27:09 GMT

rremus:

Cind am creat userul 'rremus' la sqlserver.ro in mod sigur nu am primit GRANT pe nici un obiect din baza de date. S-a creat un record al acestui user intr-o tabela, dar acesta nu este in nici un fel implicat in drepturile de access din baza de date. Toate drepturile sint acordate aplicatiei Web. Eventual aplicatia are citeva roluri definite (ex. user simplu vs. moderator) care au access la mai multe sau mai putzine module, dar astea nu se reflecta in mod sigur in nici un fel asupra drepturilor efective din baza de date. De exemplu daca in aceasi baza de date se adauga o tabela de catre o alta aplicatie, nu exista nici un mod de a restrictiona 'userii' Web sa o acceseze, intr-ucit ei nu exista ca 'security pricipals'. Ce se restrictioneaza este accessul aplicatiei Web.
In aceste cazuri nu vorbesti despre securitate in baza de date, ori discutia noastra era pornita de la avantajele SQL vs. proceduri si un argument a fost controlul accesului la proceduri prin useri si GRANT-uri. Argumentul tau (useri Web) este nu are legatura cu discutia noastra (GRANT-uri in baza de date).

cand am zis de aplicatia web aveam in cap situatii cum ar fi faptul ca tu poti sa editezi doar posturile tale si eu pe ale mele.. idee care eu zic ca se poate repeta si in alte situatii.

PS: nu am pretentia ca as fi specialist in securitate (in mod cert nu sunt) insa nu obisnuiesc sa ma multumesc cu un raspuns care nu acopera aspecte care ma interseaza chiar daca este perfect valid in alte situatii, motiv pt care prefer sa extind discutia in asa fel incat sa cuprinda tot ce ma intereseaza decat sa ignor anumite ramificatii.

in alta ordine de idei IT-ul nu este o stiinta atat de fixa ca si matematica sau fizica ci inca e in dezvoltare si continua schimbare asa ca nu vad ceva rau in a incerca sa reinventezi ceva in acest domeniu...

Re: proceduri stocate in SQL Server 2005

rremus — Thu, 07 Aug 2008 19:42:47 GMT

Gherry:

Eu eram ferm convins ca vorbim despre situatii care nu sunt acoperite de userii de windows de ex: intr-un magazin pot sa fie in acelasi timp mai multi agenti de vanzari care iregistreaza operatiile pe acelasi calculator caz in care ar fi aberant sa creem conturi de win pt fiecare si sa ii punem sa dea switch user de fiecare data.

Conturi de Windows pentru fiecare angajat sint ceva elementar in orice mediu. As vrea sa stiu ce gasesti 'aberant' in cel mai fundamental principiu de securitate de pe platforma pe care o folosesti. Si nu este nevoie de switch pentru fiecare utilizator, exista atit infrastructura de runas /user in Windows cit si posibilitatea de a integra in aplicatie schimbarea contextului curent prin LogonUser.
Bazele securitatii nu se impelemnteaza dupa 'cheful' clientilor ci prin respectarea principiilor de baza (autentificare pe baza de parola, autorizare, access controlat la 'asset'urile controlate de securitate etc). In afara cazului in care esti un specialist in securitate (si in mod sigur nu esti) orice altceva este doar o fatada goala care mascheaza exploit-uri banale, o joaca in a fi depasita pentru oricine are un interes fie si minor.

Gherry:

sau daca avem o aplicatie care lucreaza pe web sunt curios cum rezolvi problema folosind exclusiv modul de securitate SQL Server..

Userii de Web in majoritatea cazurilor nu au nimic de-a face cu autorizarea in access la date (sau orice alte resurse) ci doar cu autentificarea in aplicatie. In mediul gen web (numar mare de utilizatori, necunoscut dinainte, fara disctinctie intre ei) un 'user' nu e un 'database principal'. Cind am creat userul 'rremus' la sqlserver.ro in mod sigur nu am primit GRANT pe nici un obiect din baza de date. S-a creat un record al acestui user intr-o tabela, dar acesta nu este in nici un fel implicat in drepturile de access din baza de date. Toate drepturile sint acordate aplicatiei Web. Eventual aplicatia are citeva roluri definite (ex. user simplu vs. moderator) care au access la mai multe sau mai putzine module, dar astea nu se reflecta in mod sigur in nici un fel asupra drepturilor efective din baza de date. De exemplu daca in aceasi baza de date se adauga o tabela de catre o alta aplicatie, nu exista nici un mod de a restrictiona 'userii' Web sa o acceseze, intr-ucit ei nu exista ca 'security pricipals'. Ce se restrictioneaza este accessul aplicatiei Web.
In aceste cazuri nu vorbesti despre securitate in baza de date, ori discutia noastra era pornita de la avantajele SQL vs. proceduri si un argument a fost controlul accesului la proceduri prin useri si GRANT-uri. Argumentul tau (useri Web) este nu are legatura cu discutia noastra (GRANT-uri in baza de date).

Re: proceduri stocate in SQL Server 2005

B_gd_n[ ]Sahlean — Wed, 02 Jul 2008 08:16:42 GMT

Mai bine spus, la OCX daca modificam ceva atunci modificam implementarea si nu interfata (publica se subintelege; "Program to an interface, not an implementation").

Re: proceduri stocate in SQL Server 2005

B_gd_n[ ]Sahlean — Wed, 02 Jul 2008 08:14:25 GMT

ignatandrei:
B_gd_n[ ]Sahlean:

ignatandrei:

... tu ai facut asa ceva cu succes ?

De succes nu stiu daca este dar am apelat la o metodă simplistă:
[1] pe un server aveam un director partajat doar pentru citire (read-only share) care conţinea toate fişierele necesare aplicatiei client plus un fisier ver.txt. Fisierul ver.txt continea versiunea aplicatiei client.
[2] pe fiecare computer unde era instalata aplicatia client era instalat si un programel actualizare.exe care verifica daca aplicatia client ruleaza sau nu si apoi citea local din registrii versiunea si o compara cu versiunea de pe server din ver.txt ! Daca versiunea locala < versiunea de pe server atunci FileCopy sursă, destinaţie !

Inteleg ca aplicatia era monolitica ... nu era impartita in dll-uri si nu avea probleme de inregistrare de dll-uri, BD diferite care se puteau schimba dinamic, rapoarte definite in Crystal s.a.m.d.

Are 3 componente ActiveX OCX care au totuşi interfaţa stabilă => nu este necesară reînregistrarea OCX-urilor.
Iar rapoartele CrystalReports sunt incorporate in Exe.

Re: proceduri stocate in SQL Server 2005

ignatandrei — Wed, 02 Jul 2008 07:58:43 GMT

B_gd_n[ ]Sahlean:

ignatandrei:

... tu ai facut asa ceva cu succes ?

De succes nu stiu daca este dar am apelat la o metodă simplistă:
[1] pe un server aveam un director partajat doar pentru citire (read-only share) care conţinea toate fişierele necesare aplicatiei client plus un fisier ver.txt. Fisierul ver.txt continea versiunea aplicatiei client.
[2] pe fiecare computer unde era instalata aplicatia client era instalat si un programel actualizare.exe care verifica daca aplicatia client ruleaza sau nu si apoi citea local din registrii versiunea si o compara cu versiunea de pe server din ver.txt ! Daca versiunea locala < versiunea de pe server atunci FileCopy sursă, destinaţie !

Inteleg ca aplicatia era monolitica ... nu era impartita in dll-uri si nu avea probleme de inregistrare de dll-uri, BD diferite care se puteau schimba dinamic, rapoarte definite in Crystal s.a.m.d.

Re: proceduri stocate in SQL Server 2005

B_gd_n[ ]Sahlean — Wed, 02 Jul 2008 07:50:00 GMT

ignatandrei:
B_gd_n[ ]Sahlean:
[
Totuşi aici există tone de cod sursa pentru VB6, inclusiv pentru module/componente tip autoupdate.
+
Automatically Updating Visual Basic 6 Applications: Part I
Automatically Updating Visual Basic 6 Applications: Part II

Nu discut de linkurile de MSDN, pe care mi le-ai dat, pentru ca scriu :
"This article shows how you can add automatic updating functionality to your existing Visual Basic 6.0 applications, using features now available with the .NET Framework 2.0. (10 printed pages)"
...

Corect, tocmai din acest motiv acele 2 link-uri sunt secundare.

ignatandrei:

... tu ai facut asa ceva cu succes ?

De succes nu stiu daca este dar am apelat la o metodă simplistă:
[1] pe un server aveam un director partajat doar pentru citire (read-only share) care conţinea toate fişierele necesare aplicatiei client plus un fisier ver.txt. Fisierul ver.txt continea versiunea aplicatiei client.
[2] pe fiecare computer unde era instalata aplicatia client era instalat si un programel actualizare.exe care verifica daca aplicatia client ruleaza sau nu si apoi citea local din registrii versiunea si o compara cu versiunea de pe server din ver.txt ! Daca versiunea locala < versiunea de pe server atunci FileCopy sursă, destinaţie !

Re: proceduri stocate in SQL Server 2005

Gherry — Wed, 02 Jul 2008 07:27:14 GMT

Gherry:
B_gd_n[ ]Sahlean:

Carte este (asa cum am scris mai sus) "Applying UML and patterns", autor Craig Larman.

mersi mult, am sa o caut.

damn.. aia e de nivel intermediar - avansat.. speram la ceva scris pt bolovani dar o sa incerc sa vad cu ce se mananca, poate am noroc si se prinde si de mine ceva

Re: proceduri stocate in SQL Server 2005

Gherry — Wed, 02 Jul 2008 07:20:57 GMT

B_gd_n[ ]Sahlean:

Carte este (asa cum am scris mai sus) "Applying UML and patterns", autor Craig Larman.

mersi mult, am sa o caut.

Re: proceduri stocate in SQL Server 2005

ignatandrei — Wed, 02 Jul 2008 07:19:28 GMT

B_gd_n[ ]Sahlean:

În concluzie, pentru asigurarea persistenţei (dpmdv) sunt necesare cel puţin două nivele de abstractizare: business layer (clase tip business objects) şi data layer (clase de persistenţă).

Sunt de acord cu tine . Dar chiar asa faci ? Tendinta actuala ( vezi partial classes si LINQ 2 SQL) este sa te lase sa scrii aceeasi clasa in 2 fisiere separate - una de persistenta si una de BL

Re: proceduri stocate in SQL Server 2005

ignatandrei — Wed, 02 Jul 2008 07:16:05 GMT

B_gd_n[ ]Sahlean:
[
Totuşi aici există tone de cod sursa pentru VB6, inclusiv pentru module/componente tip autoupdate.
+
Automatically Updating Visual Basic 6 Applications: Part I
Automatically Updating Visual Basic 6 Applications: Part II

Nu discut de linkurile de MSDN, pe care mi le-ai dat, pentru ca scriu :
"This article shows how you can add automatic updating functionality to your existing Visual Basic 6.0 applications, using features now available with the .NET Framework 2.0. (10 printed pages)"

Iar celelalte coduri sursa ... marturisesc ca nu le-am incercat pe toate ... dar nu am reusit sa fac nimic serios care sa poata fi reutilizat.

Eu am programat in VB de cind era VB3 , am reusit sa fac ceva cu clasele din VB4, in VB5 am prins gustul la API-uri , VB6 m-a dezamagit ( o spoiala peste VB5 ) ... dar nu am reusit sa fac un auto-update care sa il refolosesc dintr-o aplicatie in alta...

Desi discutia este/devine obsolete, tu ai facut asa ceva cu succes ?

Re: proceduri stocate in SQL Server 2005

B_gd_n[ ]Sahlean — Wed, 02 Jul 2008 07:11:01 GMT

Gherry:

Mai intai tb sa mentionez ca asta e o bucata de teorie pe care inca nu o stapanesc asa ca daca ai putea sa imi recomanzi o carte sau un articol bun pt incepatori care sa explice simplu si clar as fi recunoscator.

Asta imi aminteste de cursurile si cartile de proiectare de baze de date cu toate teoriile care m-au cam bagat in ceata pana cand am dat de cartea lui Michael J Hernandez "Database Design for Mere Mortals" care a explicat totul intr-un mod socant de clar si simplu.

intre timp, singurul argument care il am ar fi intuitia care imi spune ca nu e tocmai ok sa imbini doua limbi in aceasi fraza.. e clar ca se poate si ca se face si probabil ca voi proceda si eu la fel insa am retineri.

Carte este (asa cum am scris mai sus) "Applying UML and patterns", autor Craig Larman.

Re: proceduri stocate in SQL Server 2005

Gherry — Wed, 02 Jul 2008 07:02:16 GMT

B_gd_n[ ]Sahlean:

Explicaţii:
[1] ce-i aia "asociere obiect - tabelă" ?!
[2] nu ar fi fost corect (retoric) "asociere obiect - înregistrare" ?!

Mi-a spus si mie la un moment dat cineva ca exista si tendinta asta: asociere obiect - tabel (insa nu am stat sa caut nimic in directia aia)

Re: proceduri stocate in SQL Server 2005

Gherry — Wed, 02 Jul 2008 06:55:26 GMT

B_gd_n[ ]Sahlean:

Personal nu vad nici o problema in "a scrie" cod SQL in clase atât timp cât acele clase NU sunt clase tip obiecte de gestiune (en. business objects sau domain classes sau domain objects) mai precis atât timp cât (în principiu ) este respectat principiul GRASP (şablonul de proiectare) "Coeziune ridicată" (en. high cohesion).

Applying UML and patterns, Larman Craig:
"
Solution Assign a responsibility so that cohesion remains high.

Problem How to keep complexity manageable?
In terms of object design, cohesion (or more specifically, functional cohesion) is
a measure of how strongly related and focused the responsibilities of an element
are. An element with highly related responsibilities, and which does not do a
tremendous amount of work, has high cohesion. These elements include classes,
subsystems, and so on.

A class with low cohesion does many unrelated things, or does too much work.
Such classes are undesirable; they suffer from the following problems:
hard to comprehend
hard to reuse
hard to maintain
delicate; constantly effected by change
Low cohesion classes often represent a very "large grain" of abstraction, or have
taken on responsibilities that should have been delegated to other objects.
"
În concluzie, pentru asigurarea persistenţei (dpmdv) sunt necesare cel puţin două nivele de abstractizare: business layer (clase tip business objects) şi data layer (clase de persistenţă).

Mai intai tb sa mentionez ca asta e o bucata de teorie pe care inca nu o stapanesc asa ca daca ai putea sa imi recomanzi o carte sau un articol bun pt incepatori care sa explice simplu si clar as fi recunoscator.

Asta imi aminteste de cursurile si cartile de proiectare de baze de date cu toate teoriile care m-au cam bagat in ceata pana cand am dat de cartea lui Michael J Hernandez "Database Design for Mere Mortals" care a explicat totul intr-un mod socant de clar si simplu.

intre timp, singurul argument care il am ar fi intuitia care imi spune ca nu e tocmai ok sa imbini doua limbi in aceasi fraza.. e clar ca se poate si ca se face si probabil ca voi proceda si eu la fel insa am retineri.

Re: proceduri stocate in SQL Server 2005

B_gd_n[ ]Sahlean — Wed, 02 Jul 2008 06:49:40 GMT

aflorin27:
crestinul:
Folositi or/m-uri si renuntati la proceduri stocate

Nu toata lumea pare sa fie de acord cu solutia asta:

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

Mult prea lung articolul şi atunci când vezi un titlu de forma "The Object-to-Table Mapping Problem" tb. să concluzionezi că articolul respectiv are cel puţin o problemă !

Explicaţii:
[1] ce-i aia "asociere obiect - tabelă" ?!
[2] nu ar fi fost corect (retoric) "asociere obiect - înregistrare" sau "asociere clasa - tabela" ?!

Re: proceduri stocate in SQL Server 2005

B_gd_n[ ]Sahlean — Wed, 02 Jul 2008 06:37:58 GMT

ignatandrei:

Draga Bogdan, VB6 nu ma opreste sa am proceduri stocate pentru CRUD.
Dar ...
1. VB6 NU ma opreste sa dezvolt un smart client (de fapt, nici un limbaj de programare nu te impiedica, odata ce ai acces la un fel de HttpRequest ... chiar si prin WinAPI)

2. VB6 imi ingreuneaza munca enorm ca sa dezvolt un SMART client = trebuie sa fac totul de la 0

Am dezvoltat odata asa ceva ... si a fost ingrozitor... Cel mai aproape s-a dovedit un smart client cu update-ul din BD

Totuşi aici există tone de cod sursa pentru VB6, inclusiv pentru module/componente tip autoupdate.
+
Automatically Updating Visual Basic 6 Applications: Part I
Automatically Updating Visual Basic 6 Applications: Part II