Programmatic Access to SP Attributes

[Alexander F. French]

Hi Scott,

I didn't mean to try and draw any conceptual distinction- just provide what I think will be a working C# .NET code sample for Chanda, and illustrate the incorrect choices that are easy to stumble in to.

The wiki explains the ideas quite clearly, but the .NET code sample at the bottom of the page is setup to send a programmer who is looking to read *attributes* in either of the wrong directions before they get to the working answer.

When I'm writing C# .NET code, I find the compiler and the runtime are pretty set on the C# .NET terminology... so it tends to be material for writing working code.

Alex

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Monday, January 29, 2018 4:33 PM
To: Shib Users <users at shibboleth.net>
Subject: RE: Programmatic Access to SP Attributes

> In .NET your attributes will be available as Server Variables:
> 	Request.ServerVariables.GetValues("HTTP_BLAH");
> 
> Attributes will *not* be available in the Request Headers:
> 	//bad
> 	Request.Headers.GetValues("HTTP_BLAH");	// won't exist
> 	//bad
> 	//you will find
> 	Request.Headers.GetValues("BLAH");	//don't use this!  It's coming
> from the user's browser and shouldn't be trusted!
> 	//bad

I don't know what distinctions you're trying to draw but:

a) The only way the ISAPI module (NOT the beta of the IIS7 module) makes the data available is in request headers, and

b) they are not from the browser, they have to be sanitized and protected by the SP by clearing them and detecting attempts to spoof them, which the module does.

They are in headers. Period. The native module changes that, allowing for either case.

What the APIs do and what they seem to be called is immaterial, it's a mess of conflicting names and weird problems that is covered at some length in the wiki since some of them are inherently risky.