Issue 185 - dotnetopenid - Unable to serialize classes implementing DotNetOpenId.Provider.IAuthenticationRequest

Issue 185:	Unable to serialize classes implementing DotNetOpenId.Provider.IAuthenticationRequest
	1 person starred this issue and may be notified of changes.	Back to list

Status:	Fixed
Owner:	andrewarnott
Closed:	Mar 2009
Type-Defect
Priority-Medium
Release-3.0

Reported by soreng, Jan 16, 2009

Is this issue relating to writing a Relying Party, a Provider, or both?
Writing a provider

What steps will reproduce the problem?
(please include the actual Claimed Identifier or OpenID Url used to repro 
the problem if possible)
1. Create a new session state store derived from 
System.Web.SessionState.SessionStateStoreProviderBase
2. Setup the store
3. Run the provider (the sample)

What is the expected output?
Nothing, the site should work as before.

What do you see instead?
An exception is thrown when the session state is serialized:
Unable to serialize the session state. In 'StateServer' and 'SQLServer' 
mode, ASP.NET will serialize the session state objects, and as a result 
non-serializable objects or MarshalByRef objects are not permitted. The 
same restriction applies if similar serialization is done by the custom 
session state store in 'Custom' mode. 


What version of the product are you using?  Official build?
DotNetOpenId 2.5.2, yes

Can this problem be reproduced using the included samples?
Yes :)

Comment 1 by soreng, Jan 16, 2009

I tried downloading the source, and added [Serializable] to all the classes that was 
used in a CheckIdRequest, and it worked :)

The easiest work-around would be to implement Serialize / Deserialize methods in 
IRequest interface.

Comment 2 by andrewarnott, Jan 16, 2009

Thanks for this report. I'm trying to understand why the default ASP.NET session 
state bag doesn't require Serializable and yet your implementation does.  Do you 
happen to know?

Owner: andrewarnott

Comment 3 by soreng, Jan 17, 2009

Well yes.

The default (InProc) session state is never serialized since it is always in memory. 
The objects are never required to be serialized.

A serialized CheckIdRequest "eats" up about 16kb of space when serialized.

Comment 4 by soreng, Jan 19, 2009

I would like to help with this issue, but I think it will be a bit more than just a 
patch, that needs to be commited. The solution I've used sofar is to just add the 
serializable-attribute to all the affected classes, but in doing that I found (what 
I think) is a few design-flaws in the project (a few small classes that could be 
made static or just contained in constants).

Do you have any pointers on how I could help?

Comment 5 by andrewarnott, Mar 06, 2009

Ouch.  I just repro'd the problem with as simple a change as (what you describe) 
changing the ProviderPortal's web.config file to use a StateServer:
		<sessionState mode="StateServer" cookieless="false"/>

I had no idea that this scenario was broken.  I'll definitely test this for v3.0 to 
make sure it works.  For v2.x, I'll have to see what's possible.  As you suggest, 
16kb per request in the session state is very costly for a simple authentication 
request.

Status: Started
Labels: Release-2.6

Comment 6 by andrewarnott, Mar 06, 2009

As you also suggested, soreng, the problem seems to stem from a design that does not 
lend itself well to serializing the authentication request due to the request 
containing references to the Provider that originally created it, which is 
undesirable to say the least.

Because of the breaking changes fixing this will entail, I'm moving this fix to v3.0, 
where breaking changes already exist.

Labels: -Release-2.6 Release-3.0

Comment 7 by andrewarnott, Mar 06, 2009

master 94ffe18e39e

Status: Fixed