ASP Authentication Providers in MOSS

ASP.NET 2.0 enables administrators and programmers to define multiple ways to authenticate users. This is done through so-called authentication providers.

Foreach IIS web application a programmer can use a different authentication provider, configured in his/hers web.config file of the application.

Because SharePoint, MOSS 2007, is ented on top of ASP.NET 2.0, you can also use multiple ways of authentication. This is done per SharePoint Web Application. When you want to have multiple ways of authentication within one SharePoint web application, you have to extend the web application across multiple IIS web sites. Each extensions of the web application will be placed in a specific zone.

For instance, you want to extend the web application towards the internet for external users(external.portal.mycompany.com). In this extensions you want to use form based authentication on top of a SQL database with the user base.
On the other hand, you want to have an internal extension (internal.portal.mycompany.com). Here you specify the standard windows authentication (is standard provided).
So, in this example you can have two ways of authentication towards the same SharePoint web application. Take in notice that you have two web.config per web application for each front-end server.

To accomplish this, Microsoft SharePoint Product group has written a kind of manual how to configure multiple authentication, see link below:
http://blogs.msdn.com/sharepoint/archive/2006/08/16/702010.aspx

Cheers.

Hidden features - some things you should know

When you're creating WSS 3.0 Features there are some things you should know:
1. features are cool
2. everyting in WSS is based on a feature
3. ... etc. etc.

I can give you many examples why you should use features, when you're are creating a WSS solution.

One thing I noticed last week, was that if you create a feature with the hidden property set to TRUE. It cannot be an activation dependent feature. So when you activate a feature that is dependent on your new secret hidden feature, it won't work.
The strange thing is, that some of the Microsoft produced features are hidden and do have activation dependencies. Very strange.

WSS 3.0 SPField derrived classes

I've been working with WSS 3.0 for some time now. One of the things I really like is to create my own fieldtypes.
Although the WSS 3.0 SDK has more To Do entries than usable explainations I managed to create my own fieldtypes.
One thing I noticed is that you cannot derrive from the SPFieldLookup. In code you can, but you have to create your own field editor, and there comes the problem. The field editor is the part where you configure the column settings. It's a user control. If you use the normal lookupfieldeditor it won't work, after de-assembling this class I noticed it will always save the field as a SPFieldLookup, and not your custom field.
So I tried to find out, where the lookupfield editor was derrived from. It implements the IFieldEditor. I started working, and coding. And done I was, I thought. It didn't work some of the SPFieldLookup members are made internal; Thank you WSS team.
How did I solve it, I derrived from a different class, the SPFieldMultiChoice field. This worked and now I have my own multi lookup, treeview field.

Below here, some examples, have fun!

My field class derrived from SPFieldMultiChoice:

public class MyLookupField: SPFieldMultiChoice
{
public MyLookupField: (SPFieldCollection fields, string fieldName) : base(fields, fieldName)
{
}

public MyLookupField: (SPFieldCollection fields, string fieldName, string displayName) : base(fields, fieldName, displayName)
{
}

public override void Update()
{
}
}

My field editor class derrived from usercontrol and implemented IFieldEditor (ascx template):

public class MyLookupFieldPropertyEditor: UserControl, IFieldEditor
{
public bool DisplayAsNewSection
{
get { return false; }
}

public void InitializeWithField(SPField field)
{
MyLookupField lookupField = field as MyLookupField;
}

public void OnSaveChange(SPField field, bool isNewField)
{
}

protected override void CreateChildControls()
{
}
}

My lookup field , field control (the field in the edit form) (ascx template):

public class MyLookupFieldControl: BaseFieldControl
{
protected override DefaultTemplateName
{
return "TheNameOfYourAscxTemplate";
}

public override object Value
{
get {}
set
{
SPFieldMultiChoiceValue values = value as SPFieldMultiChoiceValue;
}
}

protected override CreateChildControls()
{
}
}

The xml fieldtypes_*.xml file example
FieldType>
Field Name="TypeName">MyLookupField /Field>
Field Name="TypeDisplayName">My Custom lookup /Field>
Field Name="TypeShortDescription">My Custom lookup fieldtype /Field>
Field Name="ParentType">MultiChoice /Field>
Field Name="UserCreatable">TRUE /Field>
Field Name="FieldTypeClass">My.Assembly.FieldTypes.MyLookupField,My.Asembly,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=223b8b7925bde61b /Field>
Field Name="FieldEditorUserControl">
/_controltemplates/MyLookupFieldPropertyEditor.ascx /Field>
Field Name="Sortable">TRUE /Field>
Field Name="Filterable">TRUE /Field>
/FieldType>
/FieldTypes>

Both ascx template files (just some html) should be placed in the controltemplates directory of the WSS TEMPLATE hive. The assemblies should be placed in the GAC. And a fieldtypes_*.xml should be made to let WSS know you have some other field types.