Jürgen Haslauer: ASP-fragen zu session/cookies/performance/security - aufbau einer community

hallo liebe spezialisten.

bin dabei, für einen kunden im rahmen einer website eine "community" aufzubauen.
jetzt ein paar prinzipielle vermutlich sehr dumme fragen - nur leider sind die dokumentation hier nicht immer sehr zufriedenstellend.

die ganze site basiert auf asp / sql-server 7

diese community soll z.t. nur für registrierte benutzer zugänglich sein (nickname/pswd). wenn sich ein user registriert hat, sollen ihm
zusätzliche seiten bzw. zusätzliche features zur verfügung stehen.

woraus folgt, dass auf zahlreichen seiten sichergestellt werden muss, dass nur der berechtige benutzer daruf zugreifen kann.
wie sollte dies am besten bewerkstelligt werden?

man liest immer, dass man auf globale variablen verzichten soll bzw. keine session-variablen aus gründern der serverperformance einsetzen sollte.

um eine vernünftige zugriffssicherung zu erhalten, scheint es mir aber ja doch ein sinnvoller und sicherer weg zu sein.
die literatur schweigt sich leider über details zu "aus gründen der performance" aus.

wenn man cookies vermeiden kann, um infos zwischen seiten weiterzugeben, dann wäre das natürlich gut (alte "cookie/user-problematik"). und nur durch den einsatz von cookies lässt sich ja auch kein vernünftiger schutz gewährleisten. man kann zwar abfragen, ob eine id berechtigt ist - aber letztlich kann das cookie ja vom anwender geändert werden..

oder verwendet man doch session-variablen?
oder steh ich momentan nur auf der leitung mit all meinen fragen?

also nochmals üebrsichtlich:

  • was ist eine sinnvolle vorgehensweise für diese problematik?
  • worauf muss man achten, um eine vernünftige performance zu erhalten.
  • und wie ist die hardware-ausstattung in relation zur anzahl online-user zu setzen
      (so 32MB am server werden ja wohl doch für 10.000 user ausreichen, oder *grins*)
      gibt es sowas wie ein richtlinie (xxx prozessor mit yyy ram reicht sauber programmiert für zzz sessions - oder sowas in der art)?
  • hat jemand schon erfahrungen mit communities (chat, foren, clubbereiche etc).
      wo liegen performance-killer? besonders was den chat betrifft - der soll ebenfalls asp-basierend sein.

ich hoffe, ich hab hier nicht all zu naiv in die runde gefragt.
denke aber, dass die prinzipielle diskussion um den richtigen arbeitsansatz für einige interessant sein könnte.

freue mich schon auf antworten und rege diskussion

jürgen haslauer

  1. die ganze site basiert auf asp / sql-server 7

    Iiih. ;-)

    die literatur schweigt sich leider über details zu "aus gründen

    der performance" aus.

    Bei Verwendung von Session-Variablen bzw. Erzeugung von Content,
    der nur für einen User bestimmt ist, besteht in erster Linie das
    Problem, daß man die Seiten nicht mehr cachen kann. Ob es bei .asp
    noch weitere Probleme gibt, weiß ich nicht. Bei einer vernünftigen
    Anzahl gleichzeitiger Nutzer (bestehender Sessions) ist das aber z.B. bei JSP/Servlets kein Problem. Bei sehr vielen gleichzeitig bestehenden Sessions könnte es sein, daß die Speicherung der Session-Informationen im Server zuviele Ressourcen benötigt.

    wenn man cookies vermeiden kann, um infos zwischen seiten weiterzugeben, dann wäre das natürlich gut (alte "cookie/user-problematik"). und nur durch den einsatz von cookies lässt sich ja auch kein vernünftiger schutz gewährleisten. man kann zwar abfragen, ob eine id berechtigt ist - aber letztlich kann das cookie ja vom anwender geändert werden..

    I.d.R. verwendet man entweder ID+Paßwort im Cookie, oder einen
    temporären Key, der für eine Session erzeugt wird und halbwegs fälschungssicher ist (z.B. ein langer Zufalls-String).

    oder verwendet man doch session-variablen?

    Ist eigentlich dasselbe - Sessions werden auch meistens über einen Session-Key in einem Cookie identifiziert, ID und Paßwort werden dann im User-Context im Server für diese Session gespeichert. JSP/Servlets erlauben auch Sessions ohne Cookies, mit speziellen URLs (die Session-Identifikation ist in die URL codiert), was aber IMHO noch unsicherer ist.

    • was ist eine sinnvolle vorgehensweise für diese problematik?

    Eigene cookies, Sessions oder auch normale HTTP-Authentication (geschütztes Unterverzeichnis am Webserver). Falls möglich, gleich per SSL.

    • worauf muss man achten, um eine vernünftige performance zu erhalten.

    Die richtige Software verwenden und nur die Seiten schützen bzw. personalisieren, bei denen das auch nötig ist.

    • und wie ist die hardware-ausstattung in relation zur anzahl online-user zu setzen
        (so 32MB am server werden ja wohl doch für 10.000 user ausreichen, oder *grins*)

    Das hängt zu stark von der Software und der Implementierung ab, um das pauschal beantworten zu können. Am ehesten kannst du das noch anhand anderer Websites abschätzen - so hat uboot.com z.B. bei derzeit etwa 135.000 registrierten Usern ein ca. 3m breites Rack mit mehreren Linux-Kisten, davon mind. eine mit SMP.

    gibt es sowas wie ein richtlinie (xxx prozessor mit yyy ram reicht sauber programmiert für zzz sessions - oder sowas in der art)?

    Eher nicht. Meistens kann man aber durch effiziente Programmierung noch einiges aus der Hardware herausholen - d.h. wenn es eng wird, kaufst du entweder teure neue Hardware, oder du setzt dich 1 Woche hin und optimierst alles für Faktor 10 ;-).

    wo liegen performance-killer? besonders was den chat betrifft - der soll ebenfalls asp-basierend sein.

    Das merkst du schon noch beim Testen...

    freue mich schon auf antworten und rege diskussion

    Was wird es denn?

    MfG,
    -mjy