Geändertes Standardverhalten von Cookies unter NET Framework 2

Ich hatte bereits in einem anderen Blog über das Thema in Bezug auf DotNetNuke geschrieben, aber es hat ja eigentlich nichts spezielles mit DotNetNuke zu tun, sondern es ist eigentlich ein Thema des NET Framework's im speziellen des NET Framework 2.0.

So möchte ich an dieser Stelle noch einmal kurz das Thema Cookies und das geänderte Standardverhalten unter NET Framework 2 in diesem Beitrag beschreiben.

Zuerst einmal die reinen Fakten:

• Unter NET Framework 1.1 wurde die Gültigkeit eines Cookies automatisch auf 50 Jahre gesetzt (ja 50 Jahre).
• Unter NET Framework 2.0 wird ein die Dauer der Gültigkeit eins Cookies auf Standard 30 Minuten gesetzt.

Um die Gültigkeit eines Cookies unter ASP.NET 2.0 zu verändern ist der folgende Eintrag in der web.config zuständig.

Je nach Anwendung kann der Eintrag etwas anders aussehen, nachfolgend 2 Beispiele.

Beispiel DotNetNuke (Version 4.5.3 Standardwert)

Original Eintrag

    <authentication mode="Forms">
      <forms name=".DOTNETNUKE" protection="All" timeout="60" cookieless="UseCookies" />
    </authentication>

In dieser Version von DotNetNuke beispielsweise ist der Eintrag der Standardwert timeout="60" bedeutet 60 min.

Mögliche Änderung

    <authentication mode="Forms">
      <forms name=".DOTNETNUKE" protection="All" timeout="2880" cookieless="UseCookies" />
    </authentication>

Der oben stehende Eintrag bedeutet 48 Stunden Cookies Gültigkeit.

Beispiel dasBlog (Version 2.0.7226.0)

Original Eintrag

<authentication mode="Forms">
     <!-- NOTE: If you want to run MULTIPLE dasBlogs on the SAME Domain Name
      include the path in each blog's Web.Config like path="/dasblog1" and path="/yoursite"  as appropriate. -->
       <forms name=".DASBLOGAUTH" protection="All" timeout="60" path="/" cookieless="UseCookies" />
</authentication>

Mögliche Änderung

<authentication mode="Forms">
     <!-- NOTE: If you want to run MULTIPLE dasBlogs on the SAME Domain Name
      include the path in each blog's Web.Config like path="/dasblog1" and path="/yoursite"  as appropriate. -->
       <forms name=".DASBLOGAUTH" protection="All" timeout="525600" path="/" cookieless="UseCookies" />
</authentication>

Der oben stehende Eintrag bedeutet zum Beispiel 1 Jahr Cookies Gültigkeit.

Allgemeiner Hinweis:

Nachdem man diesen Eintrag in der web.config geändert hat sollte man trotzdem noch zusätzlich den Cache löschen, oder einfach das web neu starten, damit das Cookies tatsächlich das neue Timeout erhält.

Egal wie komfortabel auch ein HTML Editor sein kann, er wird nicht in der Lage sein, den Komfort zu bieten, den ein normaler Texteditor, der nicht im Internet betrieben wird, zu überbieten.

Das ist unter anderem auch der Grund warum ein Programm wie der Windows Live Writer einen Komfort beim Bloggen bietet, den man eben nur mit einem OFFLINE Editor haben kann.

Aber muss man deswegen auf irgend etwas verzichten was man ONLINE sonst hätte, NEIN !

Ich bin nach der Installation und Einrichtung des Windows Live Writer einfach nur begeistert.

Selbst Bilder sind kein Problem und werden mit der Veröffentlichung direkt auf den Webserver mit hochgeladen.

Einfach Klasse, so lässt sich doch gleich viel besser Bloggen.

Den Windows Live Writer gibt es hier

Und die Anleitung zur Einrichtung des Live Writer mit dem dasBlog gibt es hier

Und nun Happy Blogging

Übrigens wer den Live Writer gerne mit einer Rechtschreibprüfung betreiben möchte, findet hier die notwendigen Informationen.

Trotz einiger Probleme die ich während der Tests mit der neuen Version DotNetNuke 4.6.0 hatte, habe ich mich am Wochenende dazu entschlossen die Version auf meinem Deutschen Portal zu installieren.

Ich werde sicherlich zu einem späteren Zeitpunkt mehr über die Änderungen und Probleme der neuen Version berichten.

An dieser Stelle soll aber bereits auf eine neue Einstellungen hingewiesen werden, die nach dem Update automatisch aktiviert ist, die man aber besser erst einmal abschaltet, es sei denn man möchte ganz gezielt diese Option einschalten.

Ich finde schon immer, dass es nicht gut ist, die neuen Optionen als Default einfach mal zu aktivieren und somit das Verhalten des Portals ohne expliziten Wunsch zu ändern.

Aber nun zur Einstellung die ich meine:

Die Einstellung befindet sich sowohl in den System als auch in den Portal Einstellungen und dort jeweils unter dem Menüpunkt sprachen.

Es handelt sich dabei um die Funktion des Sprachparameters in der URL. Wenn man diese Häkchen nicht ausschaltet, dann verändert DotNetNuke die ursprüngliche URL und fügt ein language/de oder ähnlich je nach Portalsprache, in die URL ein.

Mehr darüber eventuell später !

Ach so, hier geht es direkt zum Download

Letzte Nacht wurde die DotNetNuke Version 4.6.0 veröffentlicht.

Wie es aussieht, haben die Jungs vom Core Team endlich die Suchfunktion zum laufen gebracht.

Allerdings gibt es ein echtes Problem mit Child Portalen. Mehr dazu wonöglich in einem späteren ausführlicheren Blog Eintrag.

Hier geht es direkt zum Download

Vermutlich ist das für die meisten nichts neues, aber ich habe nun schon einige male nach dem enrsprechenden Befehl gesucht und dabei Zeit vergeudet, aus diesem Grund mach ich nun für mich selbst diesen Blog Eintrag.

Hintergrund:

In einer Datenbank (MS-SQL) sind in einem Tabellenfeld Werte die gegen andere Werte ausgetauscht werden müssen.

Ein simples Update wie das hier:

UPDATE [TABLENAME] SET [FIELDNAME] = NEWVALUE

Nun ist es aber so, dass ich nur einen Teil des Inhaltes ändern muss, im speziellen Fall wird in der Spalte der Tabelle Informationen über den Speicherort einer Datei vorgehalten.

Hier ein Beispielinhalt:

C:\Program Files\hMailServer\Data\ihrportal\AB\{AB88191E-9A94-4C08-90B8-597A4B2FA3E2}.eml

Nun befinden sich die Daten aber nicht mehr auf dem Laufwerk C: sondern die Daten befinden sich nun auf Laufwerk D: und dort in dem Verzeichnis hMailServer\Data also auf D:\hMailServer\Data. Somit muss der Inhalt des Feldes wie folgt geändert werden:

D:\hMailServer\Data\ihrportal\AB\{AB88191E-9A94-4C08-90B8-597A4B2FA3E2}.eml

Dies muss nun bei tausenden von Einträgen durchgeführt werden.

Lösung:

Um nun die Daten in der Spalte messagefilename der Tabelle hm_messages zu ändern habe ich folgedes Query ausgeführt:

update hm_messages
set messagefilename = REPLACE(messagefilename,'C:\Program Files\hMailServer\Data','D:\hMailServer\Data')

So und nun hoffe ich das ich das nächste mal wenn ich so etwas machen möchte, daran denke dass ich dazu einen Blog Eintrag verfasst habe.

In der letzten Nacht wurde eine neue Version 0.91.2 des Open Source Anti Virus Programms ClamWin auf Sourceforge veröffentlicht.

Hier geht es direkt zum Download

Mehr über ClamWin kann man hier erfahren

Immer wieder geschieht es dass ich während der Programmierung über den zu verwendenden Zugriffsmodifizierer für Klassen und Methoden nachdenken muss (manchmal länger als ich eigentlich möchte ). Aus diesem Grund mach ich mir hier wieder mal eine kleine Gedächtnisstütze in Form dieses Blog Eintrags.

Hier nun eine kleine Tabelle in welcher man einfach den benötigten Zugriffsmodifizierer ablesen kann:

Der in C# vorhandene Operator ?? bietet einem die einfache Möglichkeit mit nicht initialisierten Objekten (null values) umzugehen.

Immer wieder muss man in der Programmierung prüfen ob ein Objekt initialisiert ist und einen gültigen Wert enthält. Hierzu hat man im allgemeinen Konstrukte wie Diese verwendet.

Zum Beispiel so:

if (myObject != null)
{
	return myObject
}
else
{
	return [defaultWert der dem Objekt entspricht]
}

Einfacher geht es jedoch mit dem in C# verfügbaren Operator ??. Dieser Operator gibt, wenn das Objekt nicht null ist den linken Wert, sonst den rechten Wert zurück.

Also so:

return myObject ?? -1;

Wenn das myObject nicht null ist, wird der Wert von MyObject zurückgegeben, ist myObject null, so wird -1 zurückgegeben.

Mehr darüber kann man auf MSDN nachlesen