Unexpected end of file. Following elements are not closed: Cookie, SecurityContextToken. Line 1, position 2998 - asp.net-4.0

I have implemented ADFS authentication for an asp.net 4.0 application. I have hosted the application in the production environment with webfarm configuration. The website works well and all the images are rendered properly in the IE8 browser. But when I tried to browse the application in the Safari browser the website does not works some times and the images are also not rendered properly.
By using Fiddler I found that the sometimes that images are not rendered properly and it comes with the following error :
Exception information:
Exception type: XmlException
Exception message: Unexpected end of file. Following elements are not closed: Cookie, SecurityContextToken. Line 1, position 2998.
Thread information:
Thread ID: 12
Thread account name: CT\acmeweb
Is impersonating: False
Stack trace: at System.Xml.XmlExceptionHelper.ThrowXmlException(XmlDictionaryReader reader, String res, String arg1, String arg2, String arg3)
at System.Xml.XmlExceptionHelper.ThrowUnexpectedEndOfFile(XmlDictionaryReader reader)
at System.Xml.XmlBaseReader.MoveToEndOfFile()
at System.Xml.XmlUTF8TextReader.Read()
at System.Xml.XmlDictionaryReader.ReadContentAsChars(Char[] chars, Int32 offset, Int32 count)
at System.Xml.XmlBaseReader.ReadBytes(Encoding encoding, Int32 byteBlock, Int32 charBlock, Byte[] buffer, Int32 offset, Int32 byteCount, Boolean readContent)
at System.Xml.XmlBaseReader.ReadContentAsBase64(Byte[] buffer, Int32 offset, Int32 count)
at System.Xml.XmlDictionaryReader.ReadContentAsBytes(Boolean base64, Int32 maxByteArrayContentLength)
at System.Xml.XmlDictionaryReader.ReadContentAsBase64(Int32 maxByteArrayContentLength, Int32 maxInitialCount)
at System.Xml.XmlBaseReader.ReadContentAsBase64()
at System.Xml.XmlDictionaryReader.ReadElementContentAsBase64()
at Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.ReadToken(XmlReader reader, SecurityTokenResolver tokenResolver)
at Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.ReadToken(Byte[] token, SecurityTokenResolver tokenResolver)
at Microsoft.IdentityModel.Web.SessionAuthenticationModule.ReadSessionTokenFromCookie(Byte[] sessionCookie)
at Microsoft.IdentityModel.Web.SessionAuthenticationModule.TryReadSessionTokenFromCookie(SessionSecurityToken& sessionToken)
at Microsoft.IdentityModel.Web.SessionAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs eventArgs)
at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
I then tried to follow the below mentioned link :
http://social.msdn.microsoft.com/Forums/en/Geneva/thread/ea00ec3f-ebdf-427c-929f-d4a196650552
But it also did not worked for me. I then tried to stop one server in the webfarm configuration and then found that the website is working fine in the IE8 and Safari browser. In IE8 browser it works all time and all the images are rendered properly but the Safari browser does not in case when both the servers in the webfarm are turned on.
On analysis I found that from ADFS I am getting some claims information in the form of cookie and the cookie length is more. For IE8 browser the cookie length is more and for Safari the permissible limit is 4097 characters.
Hence I thought of maximizing the limit of cookie for the Safari browser.
Can anyone please help me out to resolve this issue by providing any code sample.
Thanks & Regards,
Santosh Kumar Patro

The problem is now solved by enabling persistent cookies (Sticky Sessions) on the load balancer in the webfarm scenario.

I handled this issue by reducing the number of claims that are returned from STS. This will reduce the size of the cookie. I deduced another means to grab the data i needed via a service that i implemented.

Related

Serialization Exception when I upload .appxupload instead of .appxbundle to HockeyApp

When I upload a .appxbundle of my UWP app to HockeyApp, everything works fine. When I instead upload a .appxupload file, I get a Serialization error when I run my app, and try to serialize classes with the [DataContract] attribute.
The Exception I get is the following (on some machines, not all):
Value cannot be null.
Parameter name: format
at System.String.FormatHelper(IFormatProvider provider, String format, ParamsArray args)
at System.SR.Format(String resourceFormat, Object p1)
at System.Runtime.Serialization.DataContract.GetDataContractFromGeneratedAssembly(Type type)
at System.Runtime.Serialization.DataContract.DataContractCriticalHelper.CreateDataContract(Int32 id, RuntimeTypeHandle typeHandle, Type type)
at System.Runtime.Serialization.DataContract.DataContractCriticalHelper.GetDataContractSkipValidation(Int32 id, RuntimeTypeHandle typeHandle, Type type)
at System.Runtime.Serialization.DataContract.GetDataContract(RuntimeTypeHandle typeHandle, Type type, SerializationMode mode)
at System.Runtime.Serialization.DataContractSerializer.get_RootContract()
at System.Runtime.Serialization.DataContractSerializer.InternalWriteObject(XmlWriterDelegator writer, Object graph, DataContractResolver dataContractResolver)
at System.Runtime.Serialization.XmlObjectSerializer.WriteObjectHandleExceptions(XmlWriterDelegator writer, Object graph, DataContractResolver dataContractResolver)
at System.Runtime.Serialization.XmlObjectSerializer.WriteObject(XmlDictionaryWriter writer, Object graph)
at System.Runtime.Serialization.XmlObjectSerializer.WriteObject(Stream stream, Object graph)
at VungleSDK.DbTable_1`1.Serialize(T obj)
If I upload the .appxupload file to the Windows Store, I see no problems.
My question is, why is the happening? Is HockeyApp somehow modifying the .appx packages for .appxupload, but not for .appxbundle? Is something else going on?
Answering my own question:
Although HockeyApp will let you upload .appxupload files (like you can for the Windows Store), you should not. Instead, always upload the .appxbundle file.
I contacted support#hockeyapp.net, and quickly received the following response (thanks very much, HockeyApp support):
Hi Greg, thanks for getting in touch!
As the document How to sideload UWP applications indicates here it
seems we only support .appxbundle file, so please upload the
.appxbundle file instead of the .appxupload.
AppxUpload packages are meant only for the Store ingestion pipeline and I wouldn't expect them to work properly. I don't have the full rundown but they're the set of artifacts we need to properly do security patching of your application and aren't meant to be a container for execution.

ImageResizer.ImageProcessingException?

Recently I noticed that one of the production site is throwing loads of the ImageResizer.ImageProcessingException errors. At the same time RAM consumption increases dramatically leading to app pool recycle.
ImageResizer.ImageProcessingException (0x80004005): Failed to acquire a lock on file "E:\wwwroot\imagecache\1e\d1a022809295f272d4dc7c63377a759c0f336be0a1be8ca696fcf27479892cf1.jpg" within 15000ms. Caching failed.
at ImageResizer.Plugins.DiskCache.DiskCache.Process(IResponseArgs e)
at ImageResizer.Plugins.DiskCache.DiskCache.Process(HttpContext context, IResponseArgs e)
at ImageResizer.InterceptModule.HandleRequest(HttpContext context, String virtualPath, NameValueCollection queryString, IVirtualFile vf)
at ImageResizer.InterceptModule.CheckRequest_PostAuthorizeRequest(Object sender, EventArgs e)
at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
This is not a permanent issues. it does occur once or twice a day and lasts for 30-60 minutes. IIS restarts are not helping.... the rezizer is creating empty files (0 bytes). What is also interesting that the problem mostly occurs on 2 out of 3 web servers (it will start on one of them and the second will go tits up a few minutes later). The servers sort themselves out afer 45-90 minutes.
ImageResizer version: 3.4.2
What I tried:
- Upgrading to latest version
- Clearing image cache folder
- Enabling asyncwrties
Any idea what could be going on here?
Thanks,
M

ASP.NET to Mono - getting a HTTP 500. Error processing request. System.ArgumentNullException: Argument cannot be null

I'm working on my first ASP.NET to Mono port. I built a test site with several functionalities to test. One is just a simple form post. The error I'm getting is this:
Argument cannot be null. Parameter name: inputString
Description: HTTP 500. Error processing request.
Stack Trace:
System.ArgumentNullException: Argument cannot be null.
Parameter name: inputString
at System.Web.UI.ObjectStateFormatter.Deserialize (System.String inputString) [0x00000] in :0
at System.Web.UI.LosFormatter.Deserialize (System.String input) [0x00000] in :0
I tried to debug by commenting out all the code that dealt with a session variable or form input (Request.Form) but still got the error. I now have even all the code inside the page load commented out but still no dice.
This form was/is working fine as ASP.NET on IIS. Maybe there's a configuration I didn't do?
** EDIT **
I was able to pinpoint the problem to a custom Page class that I use to inherit from System.Web.UI.Page where I have overriden some of the base methods. When I switch back to System.Web.UI.Page, the error goes away. I do need my custom Page class. The error occurs when I do a form post/postback; initial load works fine.
* Problem solved * It was in the LosFormatter.Deserialize method. I had it checking if the string passed was null then revised it to use string.IsNullOrEmpty instead. Maybe it doesn't like empty strings either.

Null Reference exception DNN Core 5.6.3

My site has been running fine for sometime now until recently I see in the event viewer a null reference exception in the DNN core:
DotNetNuke.Common.Globals.GetStatus() in
F:\Builds\Maintenance\WorkingDirectory\Library\Common\Globals.vb:line
1125 at DotNetNuke.Common.Initialize.InitializeApp(HttpApplication
app) in
F:\Builds\Maintenance\WorkingDirectory\Library\Common\Initialize.vb:line
138 at DotNetNuke.Common.Initialize.Init(HttpApplication app) in
F:\Builds\Maintenance\WorkingDirectory\Library\Common\Initialize.vb:line
228 at DotNetNuke.Common.Global.Global_BeginRequest(Object sender,
EventArgs e) at
System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step,
Boolean& completedSynchronously)
the line 1125 is:
_Status = UpgradeStatus.None
Which is a property of the Globals class and an Enum
Also when this happens it doesnt just do it once then sort its self it does it roughly every minute for an hour or so.
I made sure all dataprovider.instances are either in a using or a try catch finally or self closing(if the reader is not used)
Any suggestion most welcome, as I'm officially lost.
Thanks
Similar to what ScottS mentioned, that line is setting a static enum value, so I don't see how a NullReferenceException could be thrown. Indeed, it could be a side-effect from something else.
That particular error is coming from Global.asax BeginRequest, which calls Initialize.Init(app). The only thing I can think of is to check your Http Modules. Both the RequestfilterModule and the UrlRewriteModule (which are default DNN http modules) also call Initialize.Init(app).
Perhaps check your web.config and IIS (particularly if you're running IIS 7) and make sure everything checks out?
had a look at the release.config and it have autoupdate=true set that to false and it hasnt been an issue since.

VB.NET Queue constructor Error: Queue grow factor must be between 1 and 10

First some background:
VB.NET 2005 Application that accesses a MS-SQL back-end, using multiple Web Services for data gathering/publishing.
On to the error:
Our application mysteriously crashes on one of our clients computers, it works fine on the other computers in their office, but not on the big whigs' computer, which now makes it my problem. It appears to be a software conflict of some sort as they have replaced the computer (with the same software configuration I assume) but the error still persists. I'm currently waiting to hear back from their IT staff on whether there are any known differences between this user's setup and the others in that office.
What's even more annoying is the app just disappears. We can't easily debug it as no error messages are shown, even though we have specific code in there to catch unhandled exceptions and display a message, it just closes.
However, our exception handling code is being called (at least partially) because it successfully logs this following error (just does not show it to the user like other normal errors):
Error Message: Queue grow factor must be between 1 and 10.
Stack Trace: at
System.Collections.Queue..ctor(Int32 capacity, Single growFactor) at
System.Collections.Queue..ctor() at
System.Windows.Forms.Control.MarshaledInvoke(Control caller, Delegate method, Object[] args, Boolean synchronous) at
System.Windows.Forms.Control.BeginInvoke(Delegate method, Object[] args) at
System.Windows.Forms.Form.OnLoad(EventArgs e) at
System.Windows.Forms.Form.OnCreateControl() at
System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible) at
System.Windows.Forms.Control.CreateControl() at
System.Windows.Forms.Control.WmShowWindow(Message& m) at
System.Windows.Forms.Control.WndProc(Message& m) at
System.Windows.Forms.ScrollableControl.WndProc(Message& m) at
System.Windows.Forms.ContainerControl.WndProc(Message& m) at
System.Windows.Forms.Form.WmShowWindow(Message& m) at
System.Windows.Forms.Form.WndProc(Message& m) at
System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) at
System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at
System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Now the really curious part is that we're not using Queues at all in the code that should be running at this point. (User opens app, tries to login, bam, error happens) The only Queues referenced anywhere in code is in a very specific function that is only ever run in a testing mode in-house. And it has no problems there whatsoever.
I'm kind of at a loss as to where to proceed with this problem, so any input would be appreciated.
Edit: Ok I've finally been in contact with their IT department, he was running .NET 2.0 as I suspected. I had the IT guy repair the .NET install from Add/Remove Programs and after that the problem no longer existed. So it was in fact a .NET issue
Is it possible that this user doesn't have the appropriate .net framework? I'm guessing your application requires 2.0, but maybe he/she has 3.5? Is he running a different version of windows than the other users?
The problem is not happening with your code but the lower level .net BCL.
I had a similar problem - I found this question posted looking for answers. In my case, I'd been working along fine, then updated to latest from my source code control, and after a build all of a sudden I'm seeing this problem at program startup time. Whaaa...?? How could System.Collections.Queue..ctor() suddenly be calling System.Collections.Queue..ctor(Int32, Single) where the 2nd arg wasn't between 1 and 10?
System.ArgumentOutOfRangeException was unhandled
Message="Queue grow factor must be between 1 and 10.\r\nParameter name: growFactor"
Source="mscorlib"
ParamName="growFactor"
StackTrace:
at System.Collections.Queue..ctor(Int32 capacity, Single growFactor)
at System.Collections.Queue..ctor()
at System.Windows.Forms.Control.MarshaledInvoke(Control caller, Delegate method, Object[] args, Boolean synchronous)
at System.Windows.Forms.Control.BeginInvoke(Delegate method, Object[] args)
at System.Windows.Forms.Control.BeginInvoke(Delegate method)
... my code below here ...
Reflector clearly shows this code:
public Queue() : this(0x20, 2f)
{
}
Turns out that prior to this code executing, I was P/Invoking to native code through a P/Invoke signature that did not match the native code (which had changed in SCM). (My build process did not properly copy the updated native DLL into the correct location.) So somehow the stack was corrupted at that point, leading to this unexplained badness.
That's one of the things I'm waiting to hear back from their IT staff about. Our app requires at least .NET 2.0, but I haven't personally done any testing with 3.5, I might have a chance to look into it later today..