MOSS2007 - RSS Feed WebPart mit Proxy Authentication 
Donnerstag, Januar 17, 2008, 01:57 PM
Das Problem haben sicherlich schon viele SharePoint Entwickler gehabt: Man will ein simples RSS-Feed WebPart einbinden um z.B. Nachrichten anzuzeigen und bekommt stattdessen eine Fehlermeldung.
Nun, meist liegt das daran, dass man für http Zugriff aus dem Firmennetz zwingend über den Proxy-Server gehen muss. Kein Problem eigentlich, denn schließlich muss man nur in der web.config folgende Zeilen hinzufügen und seinen Proxy-Server eintragen und einen IISReset durchführen:


<defaultProxy>
<proxy proxyaddress="http://proxyserver:port" bypassonlocal="True" />
</defaultProxy>



Das funktioniert aber leider nur, wenn der Proxy-Server anonymen Zugriff erlaubt, denn ist SharePoint für NT-Authentifizierung konfiguriert (das ist meist so), werden keine Credentials weitergereicht, so dass der Proxy die Verbindung verweigert. Leider kann man aber nirgendwo angeben, welche speziellen Credentials SharePoint für den Proxy-Server verwenden soll!
Ein Workaround ist auf jeden Fall, auf dem Proxy die IP-Adresse des SharePoint-Servers freizuschalten, so dass anonyme Zugriffe von dort erlaubt werden. Falls das aber nicht möglich ist, weil die zuständige IT-Abteilung im Unternehmen dies nicht zulässt, hat man zunächst keine Möglichkeit mehr, ein RSS-WebPart zum Laufen zu bringen.
Ob eine Umstellung auf Kerberos das Problem beseitigt, konnte ich bisher nicht testen.

Um dennoch RSS-Feeds anzeigen zu können, habe ich schließlich selbst einen kleinen "Proxy" geschrieben, der sich am Proxy-Server anmeldet und den Request zum WebPart durchschleift! Dadurch erspart man sich Konfigurationen und Diskussionen, muss aber eine neue kleine Webseite einrichten - am besten auf dem SharePoint Server selbst.

Eigentlich ist es ganz einfach:

1. Neues VisualStudio Projekt anlegen vom Typ ASP.NET Web Application

2. Default.aspx leeren, bis auf die Header-Zeile mit der Page-Direktive

3. In der Page_Load Methode folgenden Code einfügen:


string feedUrl = Request.QueryString["feedurl"];
HttpWebRequest request = (HttpWebRequest)WebRequest.Create(feedUrl);
request.Proxy = new WebProxy("http://proxyserver:port", true);
request.Proxy.Credentials = new NetworkCredential("UserNameForProxy", "PasswordForProxy");
HttpWebResponse rssResponse = (HttpWebResponse)request.GetResponse();
Stream responseStream = rssResponse.GetResponseStream();
Encoding enc = Encoding.GetEncoding("ISO-8859-1");
StreamReader reader = new StreamReader(responseStream, enc);
string str;
str = reader.ReadToEnd();
Response.Clear();
Response.ClearContent();
Response.Write(str);
rssResponse.Close();



4. Das Ganze kompilieren und auf den SharePoint-Server in ein Verzeichnis im Inetpub publishen.

5. Im IISManager eine Webseite dafür einrichten (ich habe localhost und einen freien Port verwendet) - nicht vergessen auf .NET 2.0 umzustellen.

6. Im RSS-WebPart die URL unserer gerade erstellten Webseite eintragen, und als feedUrl-Parameter den eigentlichen Feed setzen:
z.B.:
http://localhost:6789/Default.aspx? feedUrl=http://www.news.de/rss_news.xml


Und voilá - das WebPart lädt die Seite.

Theoretisch kann man zwar jede Webseite so laden, allerdings werden hier relative Pfade von Bildern, oder CSS-Dateien nicht umgeschrieben, so dass eine normale Webseite nicht korrekt angezeigt wird. RSS-Feeds enthalten aber meist nur absolute Pfade, so dass es hier kein Problem geben sollte.


Hinweis:
Benutzername und Passwort sollte man lieber aus der web.config lesen, und möglichst einen speziellen Benutzer verwenden, der ansonsten keine Rechte hat.
Die "feedUrl" kann man natürlich komplett per Query-Parameter übergeben, aber aus Sicherheitsgründen habe ich feste URLs definiert, die man über einen frei definierten Namen per GET angibt. Dann muss man auch nicht die URL beim Aufruf encoden.

  |  Permalink   |  Related Link

InfoPath 2007 + FormServer - Eingabebegrenzung für mehrzeilige Textfelder 
Donnerstag, November 1, 2007, 04:52 PM
Wenn man InfoPath mit Forms Services benutzt, hat man oft mit Beschränkungen zu kämpfen, die sehr lästig sein können. So ist es z.B. aus HTML-Technischen Gründen nicht von Natur aus möglich, einem mehrzeiligen Eingabefeld eine Zeichenbeschränkung aufzuzwingen. Das Feld ist schlicht ausgegraut:



Das kann sehr nervig sein, wenn man die InfoPath Daten in eine Datenbank speichern möchte, und das Zielfeld nur eine begrenzte Länge hat. Es wäre schön, wenn man die Fehleingabe schon im Browser abfangen könnte.
Mit einem kleinen Kniff kann man dies jedoch auch für die mehrzeiligen Eingabefelder erreichen.
Dazu muss die Validierung für das betreffende Feld eingeschaltet werden: "Data Validation"



Für die Validierung wählt man ein eigenes "Custom Pattern", was letztendlich nichts anderes ist als eine Regular Expression:



Als Pattern wählt man dann einfach folgende RegEx:

(.|[\r\n]){0,255}



Wobei hier 255 Beispielhaft die maximale Anzahl der erlaubten Zeichen ist.
Dadurch darf jedes beliebige Zeichen, inklusive eines Zeilenumbruches eingegeben werden, und zwar mindestens 0-Mal, und maximal 255-Mal.
Der "ScreenTip" wird dann über der Box eingeblendet, und die Eingabebox ist wie gewohnt rot umrandet:




  |  Permalink   |  Related Link

MOSS 2007 - SSL Aktivieren 
Donnerstag, Oktober 4, 2007, 01:32 PM
Eine bestehende WebApplication in MOSS, die unter http läuft, kann relativ einfach auf SSL umgestellt werden.
Über den folgenden Weg kann man seine Site umstellen und mit einem selbst generierten Zertifikat versehen (für Testzwecke).
Hat man später ein gültiges Zertifikat einer Zertifikatsstelle, tauscht man dieses einfach im IIS aus.
Hat man bereits ein Zertifikat, braucht man das Resource-Kit natürlich nicht zu installieren.

1. IISResource-Kit downloaden (iis60rkt.exe) und installieren

2. Zertifikat erzeugen und zur IIS Site hinzufügen:
c:\>selfssl /N:CN=*.<domainname.tld> /K:1024 /V:3650 /S:<IISSiteID> /P:443
z.B.:
c:\>selfssl /N:CN=*.example.com /K:1024 /V:3650 /S:1234567890 /P:443

3. Secure Bindings für die Webseite setzen:
In den Ordner wecheln, in dem die adsutil.vbs Datei liegt (z.B.: c:\Inetpub\AdminScripts)
c:\>cscript adsutil.vbs set /w3svc/<IISSiteID>/SecureBindings ":443:<Domain>"
z.B.:
c:\>cscript adsutil.vbs set /w3svc/12345567890/SecureBindings ":443:portal.example.com"
iisreset

4. c:\>iisreset

5. In der CentralAdministration die URL auf https:// umstellen (nur die URL ändern):



Quelle:
http://mcmsfaq.com/cs2/blogs/adrian_spe ... 7/205.aspx
http://www.plijnaer.nl/weblog/2007/08/m ... s-and.html

  |  Permalink   |  Related Link

Access Denied Meldung bei Feature Aktivierung 
Freitag, August 10, 2007, 09:49 AM
Unter Umständen kann es beim Versuch, ein Feature für eine Site Collection zu aktivieren, zu einer Access denied Fehlermeldung kommen. Insbesondere wenn man das Feature
Office SharePoint Server Publishing Infrastructure
aktivieren möchte.

Ursache sind falsche Berechtigungen der Application Pool User, die oft bei einer SharePoint Installation mit 8-10 verschiedenen Minimal Rights Usern Ärger bereiten. Je mehr man sich bemüht alles richtig zu machen und möglichst viele verschiedene AD User für alle Bereiche während der Installation anzulegen, desto schlimmer wird es später...

Um das Feature zu aktivieren, kann man entweder dem Application Pool User, unter dem die aktuelle WebApplication läuft, Lese/Schreibrechte auf die Datenbank der Central Administration geben, oder man tauscht den User kurz gegen einen anderen aus.
Am besten ermittelt man den Benutzer der Central Administration, indem man sich im IIS die Eigenschaften der CA Webseite anschaut, und den Benutzer unter dem Karteireiter "Identity" herauskopiert.
(Das Passwort sollte man natürlich kennen)



Diesen User trägt man dann als Identity für seine andere WebApplciation ein, und führt einen IISReset durch. Danach sollte man das Feature problemlos aktivieren können. Anschließend setzt man den alten AppPool User einfach wieder zurück und lässt nochmals einen IISReset laufen.


  |  Permalink   |  Related Link

InfoPath - Datentyp eines Feldes ermitteln 
Freitag, Juni 1, 2007, 10:56 AM
Wer schon einmal versucht hat, die Daten eines InfoPath Formulars über einen Webservice in eine Datenbank zu schreiben, wird sicherlich auch versucht haben, den Datentyp der ursprünglichen XML-Felder zu bestimmen um ggf. Konvertierungen durchzuführen.
Leider erhält man beim Versuch, den Datentyp per Code zu ermitteln, immer String als Ergebnis.
Ein Blick auf das XML eines XPathNavigator Objektes einer DataSource verrät, dass hier auch gar keine Datentypen hinterlegt sind, und diese auch folglich nicht ausgelesen werden können. Die gesamte Schema-Information befindet sich nämlich in der MySchema.xsd Datei, die sch z.B. in der fertigen .xsn des Formulars befindet.

Um den Datentyp zur Laufzeit dennoch ermitteln zu können, kann man über die OpenFileFromPackage Methode des Template Objekts auf die MySchema.xsd zugreifen:

public void pbStart_Clicked(object sender, ClickedEventArgs e)
{
string sType = "";
XmlDocument doc = new XmlDocument();
doc.Load(this.Template.OpenFileFromPackage("myschema.xsd"));
XmlNamespaceManager nsmgr = new XmlNamespaceManager(doc.NameTable);
nsmgr.AddNamespace("xsd", "http://www.w3.org/2001/XMLSchema");
XmlNodeList list = doc.SelectNodes("//xsd:element[@name='Geburtstag']", nsmgr);
sType = list.Item(0).Attributes.GetNamedItem("type").Value;
doc = null;
}


Danke an Daniel, der diesen Weg herausgefunden hat!


  |  Permalink   |  Related Link


Zurück Weiter