Nu pratar vi om olika saker tror jag. Det du ändrar i web.config är för SessionState hanterarn. T.ex om du har flera servrar som delar på belastningen så måste de ha en gemensam källa att spara session informationen på. Det är det som specifieras i den kod du visar. Jag tror att du är ute efter att spara connectionstring för att koppla upp dig mot din egna sql server för att hämta data av något slag. Det görs enklast med mitt exempel. Hoppas jag förstod rätt nu :)
...sen är det väl inte supersäkert att lägga sin connectionstring i webconfig, koden ligger ju öppen, blir det strul med webbservern så... då slår jag än en gång ett slag för registret! En nyckel i registret går definitivt inte att komma åt från nätet lika lätt samtidigt som du har kvar fördelen i att slippa kompilera vid eventuella ändringar. :)
Precis... och detta har vi inte diskuterat förr :)
Fast har man det liggandes på ett webhotell får man dessvärre inte ändra så värst mycket i registret. Men ibland kan man få en mapp som ligger utanför rooten och där kan man då placera en xml fil innehållande connectionstring. Det måste väl vara den lättaste lösningen på ett webhotell.
Jag bryter mitt löfte, och luftar mina tankar... ;)
där kan man då placera en xml fil innehållande connectionstring.
Det borde vara osäkert också. Man får fram XML-filens namn, och vips får man tag i alla uppgifter genom att skriva in URL:en till den.
Om man gömmer den i affärslagret så blir den mycket svårare att komma åt, om man inte har tillgång till registret då.
nej!
"ibland kan man få en mapp som ligger utanför rooten och där kan man då placera en xml fil innehållande connectionstring."
Om inte filen ligger i root katalogen eller en underkatalog kan den inte hämtas via att man skriver in url. Och med root menar jag då att den map där t.ex default.aspx ligger :)
Jag håller med om registret som ett lämpligare ställe att lagra lösenordet i (själva connection-stringen i övrigt skulle jag behålla i xml-filen).
Sedan låter man endast IIS:ens användare ha läs-access till den nyckeln. Den som administrerar IIS:en bör väl åtminstone kunna skriva dit.
Vidare använder man CAS (code access security) och låter bara det assembly:t som ska komma åt connectionstring:en ha RegistryPermission dit.
Är lösenordet känsligt så kan man överväga att skydda det med CryptProtectData() innan man lagrar det (vilket är vad Microsoft och andra rekommenderar för "storing secrets"). Lämpligt exempelvis om man connectar till en 3:e part och har ett lösenord dit som man är rädd om. Men nu har jag halkat off-topic.
Det är ju det jag säger hela tiden! Affärslagret = dina bakomliggande komponenter.
Wee, affärslager var ett ord som gick långt över mitt huvud... :stud
NETwork kan du förklara hur du lägger in det i registret och hämtar det från registret ?
Under länken nedan finns ett litet exempel som du kan starta med. Sedan kan du naturligtvis utveckla handhavandet och göra det hur sofistikerat som helst (läs exempelvis Developers inlägg ovan). Behöver du mer hjälp så är det bara att fråga igen. :)
Visst kan man använda COM+, men vad tillför det egentligen som du inte kan göra med Registry?
Det är mycket besvärligare att göra, installera, konfigurera och administrera en COM+ komponent än att använda Registry eller en XML-fil. Dessutom är det knappast möjligt om man har en hostad miljö.
138 ms totalt · 3 externa anrop · v20260731065814-full.b746b907