ok, nog om detta nu :)
Vad tror ni är smartast!
92 svar · 2 300 visningar · startad av Nickemannen · sida 4 av 5
Frågan, av Nickemannen
Vad tror ni är smartast! Lägga datbaskopplingsträngen i global filen eller tar det för mycket minne? eller ha med en include fil? kan ju bli jobbigt om man skall byta lösenord eller något senare. OBS! jag menar bara strängen t.e.x String strConn = "server=(local)\\NetSDK;database=pubs;TrustedConnection=yes";
Läs frågan i sin helhet →Om man får lägga sig i den intensiva uppkopplingsdebatten ;) så finns en annan smidig lösning om ni inte vill kompilera om vid eventuella ändringar... nämligen att lägga in en nyckel i registret och hämta sökvägar och annat skit till databasen från denna. Smidigare än att skapa en xml-fil i alla fall... tycker jag.
I registret? Om man programmerar en webbsida?
Det låter inte som en enkel lösning, eftersom att man då måste ändra i registret på alla burkar som sidan ska köras på. Komponenter och XML-filer är ju bara att tanka upp. :)
Vi använder registret hela tiden, det finns många fördelar med den metoden, inte minst om du ska sälja applikationen och göra installationsfiler och liknande. Ett alternativt sätt att lösa det på är det i alla fall... helst då tillsammans med en klass mot databasen naturligtvis.
Jag skulle inte vilja kalla det för "programmera en webbsida" ... programmera en webbapplikation låter mycket trevligare. Det är mer program än "en sida på internet", numera. :)
Okej, men då beror det ju på vad du skall ha det till. Antar att ditt
exempel är bäst om man skall göra ett intranet.
Och att den inte är det om man gör en såkallad vanlig hemsida?
Ett annat sätt som jag anser vara det kanske bästa om man vill skydda sin Databas-sträng, är att lägga den i COM+.
Skapa en klass som refererar in "System.EnterpriseServices" och som implementerar "construct"-metoden. Typ:
Public Class ComPlusConnStr
Inherits System.EnterpriseServices.ServicedComponent
Public Shared strVal As String
Protected Overrides Sub construct(ByVal strConstructVal As String)
strVal = strConstructVal
End Sub
End Class
Skapa sen en "Strong-key" i .Net prompten:
sn -k c:\connStr.snk
...och lägg till den i "AsseblyInfo.vb" i klassen som "AssemblyKeyFile":
<Assembly: AssemblyKeyFile("C:\connStr.snk")>
Lägg till Asseblyn i COM+ via .net Prompten:
regsvc /appname:ComPlusConnStr comPlusConnstr.dll
En ny applikation har nu skapats i COM+ där Assemblyn ligger.
Högerklicka på Assemblyn i COM+ välj Properties och Activation.
Kryssa i "Enable Object Construct" och skriv i Databas-stängen i "Constructor string".
Skapa nu ett nytt projekt och referera in både Assemblyt och System.EnterpriseServices.
Nu kan du hämta ut stängen från COM+:
Dim obj As New ClsComPlusConnStr.ComPlusConnStr()
MsgBox(obj.strVal)
På det sättet kan Sys.Adm. skydda databasstängen, inte bara från olaga intrång, utan även från "obehörigt" folk som kan råkas finnas på kontoret (praktikanter osv).
Lite mer jobb i steg 1, men sen funkar det klockrent!
Registret blir problem om man har grejerna liggandes på ett webhotell. Tror inte de tillåter att man ändrar registret. Den bästa lösningen om man har det liggandes på ett webhotell med bara FTP åtkomst är att lägga det krypterad i appSetting i web.config. Att ha det i konstruktorn för ett databasobjekt i en .aspx sida är lika osäkert som att ha den i web.config.
Varför skulle det vara osäkert att ha det i konstruktorn?
eftersom om något går snett med .NET som övervakar alla request mot IIS så skulle en .aspx sida kunna visas i klartext. Då kommer ConnectingStringen att stå i klartext med lösenord(om man använder det dvs.) och allt.
Hm, om något går snett i .net så utgår jag från att den ändå inte av misstag kastar fram hela sidan, VÄL!? Använder du dessutom code-behind så har du ju ingen kod i din .aspx-sida... försök att få fram något ur en dll-fil och du är duktig (om du mot förmodan överhuvudtaget får fram filerna alls).
jag använder CodeBehind, men det exempel SPiN pratade om var utan det vad jag förstod. Det jag menar med går snett är att om t.ex .NET skulle sluta fungera så kommer .aspx sidan behandlas som vilken annan text fil som helst och därmed spotta ur sig hela koden.
Renholm och NETWork:
Den ligger som tidigare sagt i kontruktorn för COM+ objektet. Inte i kontruktorn för aspx-klassen...
Enda sättet att komma åt den är att starta COM+ hanteraren och därigenom ändra strängen.
I aspx koden skriver man bara:
Dim obj As New ClsComPlusConnStr.ComPlusConnStr()
Dim strDBStr = obj.strVal
Det är alltså inte kontstruktorn för aspx-klassen.
Fördelen är då även att det är enkelt att ändra databas-sträng (För den om har behörighet till COM+) utan att behöva ändra några assemblys.
ok, men när jag skrev mina inlägg så hade de inget med din COM+ lösning att göra... men den är bra, ska kika mer på sådant.
Ok! Sorry :)
Man lägger in det via COM+ (står i mitt exempel, se några inlägg tidigare...)
Högerklicka på Assemblyn i COM+ välj Properties och Activation.
Kryssa i "Enable Object Construct" och skriv i Databas-stängen i "Constructor string".
Har du något färdigt exempel hur en sådan lösning kan se ut, en hel lösning där COM+ används för att hämta och skriva data.
Om du följer instruktionen i mitt föregående exempel:
http://www.webforum.nu/showthread.php?s=&threadid=46514&perpage=25&pagenumber=3#post399776
så får du all logik i både Assemblyn och i klienten för att använda "Object Construction" från COM+.
I det exemplet gjorde jag bara msgbox på värdet, men det kan lika gärna användas för att öppna en datakälla. ex.
Dim obj As New ClsComPlusConnStr.ComPlusConnStr()
Dim cnObj as new sqlConnection(obj.strVal)
Om vart man ska spara ConnectionStringen så såg jag detta på www.asp.net:
9. Update the Web.config 'connectionString' setting in <installpath> to point to the database and to use the uid/pwd of your
I installationsanvisningarna för ASP.NET Forum
cya,
PatrikB
