i am using file upload on the user front. is there any way if some exception occurs the html file control is able to persist its value on post back(i know it can't) but any work around?. i am using server side validations.
This could get messy.
Just a couple of points,
If an exception occurs do you really think it is wise to save the file?
By its nature an exception is telling you an error has occurred and processing should not continue. I would think the only time you should save the file is when you can recover or handle the exception without any side affects.
In which case you have to ask yourself, can you not just prevent the exception in the first place?
Always, always do validation on BOTH client and server side.
Why? Well to prevent this sort of thing, at least as much as possible. Let the user know there is a problem before posting, much better experience for them.
It terms of the problem, the best thing you could do is potentially keep the file path, and if an error occurs put that value back into the input box.
This wont be pretty, the input type for files is one of those special cases where the browser is responsible for a lot of the user interaction.
Remember in most cases what is happening is the browser is collection the byte information from the file and passing that around as part of the request, this is not something you are going to be able to manipulate easily.
Related
I am trying to pass variables from one page to another using Sessions , but they don't seem to have effect. In the source page inside the razor syntax
Session["variable"] = "value";
And in the target page:
<p>#Session["variable"].ToString()</p>
but I get a server error
Exception Details: System.NullReferenceException: Object reference not set to an instance of an object.
Any suggestions would be most welcome........Thanks
I was only ever able to get this to work with casting:
<p>#(string)Session["variable"]</p>
Although it has been a long time since I have tried it with ToString() instead, I do explicitly remember my attempt to call a Session variable only successful with the casting option, although I have heard that ToString() should work. Either way, I always get it to work with casting.
That having been said, I feel it only right of me to warn you that if you are simply trying to pass data between pages, you shouldn't be using Session variables at all. Use hidden form fields, query strings, Url Data, or even cookies and/or databases before you do that.
I like to look at Session variables as something to quickly solve very special cases and only to be used very CAREFULLY. ALWAYS expect the value to be null and test its value before using it.
For help with the options for transferring data between web pages using WebMatrix, check out Mike Brind's very helpful site: http://www.mikesdotnetting.com/Article/192/Transferring-Data-Between-ASP.NET-Web-Pages <-- You'll want to bookmark this for now. It is right up the alley of what you are getting yourself into with WebMatrix.
If you still want to use the Session variable and casting doesn't work, the only other thing I can think that would cause the error is that the value you expect in Session["variable"] isn't what you think it is.
For the Record:
I was only trying to make a point when saying, "or even cookies and/or databases before you do that" Please do not use those options, as they are likely terrible in your case (also, cookies would just give you the same problems as Session variables, actually). In any case, it really all depends on how you are using the data and if you are always checking to make sure the value hasn't been cleared in the case of Session variables and/or cookies.
This is my first time doing a project in ASP so this is my first time running into the dreaded A potentially dangerous Request.Form value was detected from the client... error.
I've looked around the web and stackoverflow, and can't seem to find a "best practice" way to deal with this. I don't exactly want to turn off all validations, because that would mean that in every single text box where the user can input data, I need to have to encode/decode the text myself right? Which leads me to think that this is a very easy way to leave security holes in your site.
Another seemingly common fix is to have the validation break gracefully and lead to a nicer looking error page for the user, which isn't a bad fix, but it can't be the best right?
I've noticed on most sites, if you enter the HTML encoding for a apostrophe for example, it automatically turns into a apostrophe character. As I type this now, if I try to type in ' ; (take away the space between 9 and ; and this is the HTML encoding for apostrophe), it automatically gets converted into a '. There has to be a way in ASP.net 4.0 to do the same thing?
Btw, I'm using c# as my backend server side code.
Folks,
I have an application that is primarily one page with a lot of user controls and custom controls. ASP.Net WebParts are being used. There is almost no code in the web page and its master page: it's all in various components.
The design requirements include an error message display panel. The client would like the app to display any errors occurring in any part of the app on the error message display rather than going to a custom error page. (This was a recent decision: when we started we were thinking custom error page.)
As far as I can tell, WebParts don't provide any default error handling (no capture of errors and displaying of messages) and user controls don't necessarily fire their OnError event when an internal error occurs.
So I'm looking at wrapping absolutely everything in Try ... Catch blocks, at least at the presentation level, and doing the handling. So my question is: is there any easy way to implement a kind of global, or at least class-wide, error handler, that will handle an error in the way I choose, interrupt the routine that was executing, but return (after handling) to the caller of the method that failed?
I'm willing to adapt code to verify that subroutines did what they were supposed to and returned appropriate values (ex: non-null data objects.) What I don't want is for the whole process to be aborted up to the very top, with rendering skipped, or (of course) the famous yellow and white screen.
I guess this is a case for aspect-oriented programming, but I don't think ASP.Net provides anything like that yet. I didn't get the impression that EntLib 5.0 did, either.
I would adore it if it were possible to decorate a method with an attribute that meant "On error call such-and-such a static method of such-and-such a class". But I doubt it is, yet.
Any suggestions are welcome.
Thanks,
Ann L.
For starters, it's bad practice to put Try Catch handlers around every piece of code in your application. There is a slight performance hit every time you set that up, and this could slow things down really fast.
In your Global.asax.cs (or .vb) file, there is a method in there called Application_Error which is the global error handler. This will catch any error you haven't previously caught (or thrown up) within the application.
You could easily put your error handling code here. It could be as simple as dumping the error message to a log for future review, or check for the exception type (SQL vs. File vs. HTTP) and do the error handling task related to the type.
You need to take a look at elmah. If you google 'elmah' it has an error module/handler that does pretty much what you are looking for (although it will take some extra tweaking..)
You might want to consider letting your errors 'bubble up' though.. There are some serious performance issues with writing a bunch of Try..Catch..Finally blocks...
This is quite a lengthy post, so bear with me. I'm not sure whether it is primarily about ASP.NET Session State behaviour, NInject, application design, or refactoring. Read on and then you can decide... :-)
Background
First, a bit of background. We are working on trying to refactor a large webshop into a more maintainable , structured design. The webshop is currently running on .NET 3.5, but the design is more of a hangover from the classic ASP days. Obviously we cannot tackle everything in one go, so many of the features / technologies / approaches have to be taken as a given. With that in mind...
The app maintains everything to do with the current session (user profile, cart, session choices, etc.) in a context object which is simply a large XML document that gets serialized to and deserialized from the Session as a string. The XML format is also important because the rendering is done via XSLT.
This has led to a number of problems :
It's a kind of God object with far
too many concerns.
It's loosely typed and relies too much on XML manipulation / XPath.
There is no standard way / pattern for retrieving the session xml document or for writing it back. We have a horrible mixture of methods that take the document in as a parameter, modify it and return it, methods that retrieve it themselves, modify it and save it back to session, etc, etc. This has lead to a lot of hard to trace bugs, over-use of serializing /deserializing from the Session, etc.
Our Solution
What we have done is try to introduce a strongly -typed wrapper around the xml document, which breaks it up into different concerns and to manage the lifecycle transparently to the rest of the app.
What we are aiming for is the following workflow:
Beginning of the request, we populate
the session document from the xml
string stored in the session.
The rest of the app interacts with it
only through the strongly typed
wrapper. The whole app uses the same
instance and does not have to worry
about when to retrieve or save the
state back to session.
At the end of the request, the underlying xml document is serialized back to the Session.
Since we are using NInject(v1) as the IOC of choice, we decided to use this to manage the lifecycle of our context object. The context object was wrapped with the OnePerRequest attribute and the dispose method was hooked up to a method that would save the xml document back to Session as a string.
It doesn't work...
We soon encountered a problem that the NInject OnePerRequest module didn't appear to have access to SessionState. The first thing we tried was a hack that we would keep the Session object in a variable to make sure we could still write to it. This appeared to work on a development machine but it became obvious it didn't when moving to out of process state.
It still doesn't work...
We tried inheriting from the OnePerRequest behaviour / module, and adding the IRequiresSessionState marker interface (OnePerRequestRequiresSessionState). However, this was not enough as the method which NInject uses to release references and clean up gets hooked up to the EndRequest method. Session is available in EndRequest but it has already been serialized to the out of process state server so changing something now is not reflected when the session string is retrieved at the beginning of the next request.
We then decided to change the even t to hook up to. We ditched EndRequest and hooked up our OnePerRequestRequiresSessionState "release all" method to the PostRequestHandlerExecute event, which is BEFORE the session data gets serialized out of process.
It works... then it doesn't...
This seemed to work. On a single server and on a web farm. Then we noticed weird behaviour. There seemed to be two different versions of the context and you would randomly switch between them. Add something to the cart, it's not there. Go to browse to another product and the previous product would show up in the cart.
After some tracing, we discovered the culprit: Response.Redirect. Sprinkled throughout the site in literally hundreds of places is Response.Redirect(url);. With this version of the redirect, the execution of the page is stopped immediately. This means that PostRequestHandlerExecute is not fired and the current version of the Context object is not thrown away by NInject... and everything falls apart. New versions are not created properly, etc. EndRequest is fired which is why the normal NInject OnePerRequest module works fine with it, just not our bastardized version that tries to use session state.
Of course, there is an override to Response.Redirect where you can pass a boolean value in to tell it whether to terminate the existing page or continue to execute - Response.Redirect(url,false). Continuing obviously fires our event and everything works but... it continues to execute the rest of the page! This means executing everything that comes after the call to Redirect and we have absolutely no idea what that means (since the existing site expects it to stop).
What next?
So, any suggestions on what to do? So far we've discussed :
Abstracting our redirect behaviour
and going through a central method
that controls the redirect (perhaps
hacking out a way to call the
PostRequestHandlerExecute even t or
maybe a custom Redirect event that
our NInject module can also
subscribe to and clean up).
Seeing if there is a way we can
force the Session object to save in
EndRequest if it hasn't been saved
previously in
PostRequestHandlerExecute, and do
the ninject clean up in EndRequest
Remove our dependency on Session
completely and use another storage
mechanism: DB, document DB,
distributed HashTable, etc. Any
advice? Suggestions we haven't
thought of? Things you've tried
that have / haven't worked?
I think you're on the right track. Here's some thoughts I had:
in addition to the strongly typed wrapper you have, I'd suggest a facade for accessing the context object that returns your wrapper, something like an IContextProvider. that way you can introduce it piece-meal, and then when it's fully integrated, you can refactor the provider without breaking the things that use it. I can't tell, but you might have already done this. it'll also be easier to change your persistence mechanism if you choose to. if you can do this, I would suggest once you get all the dependencies isolated from the context object, change it to not persist as XML. the SessionState will store a binary object much faster, and you can always serialize to XML if you need to do transforms.
I don't think that Ninject is the correct mechanism for what you're trying to do. it's difficult to signal end of the request in Ninject, since garbage collection can't be depended on. have you considered using an IHttpModule instead? you can use the AcquireRequestState and ReleaseRequestState or EndRequest to handle getting/setting the context in Session. only allow the app to get to the context object through the facade.
if you're on a webfarm, you're probably using a database for your Session storage anyway, so putting your context into a DB won't be much different.
Firstly, while it's good to demonstrate you've put in the work, (and I and others may not have replied if it wasn't clear how much you're interested in a resolution)... that's a massive wall of text! Here's a +1 on your way to investing in a bonus for a complete response that talks about the Ninject ASP.NET extensions and how they apply to each individual element of your issue. Having said that, hopefully someone will come along with a real resolution for you.
Even though it's [very] 2.0 specific, Nate's Cache and Collect Post is required reading. While it seems you're pretty au fait with the tradeoffs involved and have debugged deep in, the article is well worth a few reads.
I'd also consider moving to V2 of Ninject - a lot of this stuff has been revised significantly. It's not magically going to work, but represents a mature rewrite based on a lot of learning from V1. Have you read the (V1 or) V2 unit tests for Ninject? They'll show you the low level tools at your disposal in order to realise your goals.
Bottom line for me is that you need to work out a strategy for your state management independent of DI, and then by all means use the container/DI system as a part of the implementation.
We got a long-running website where XSS lurks. The problem comes from that some developers directly - without using HtmlEncode/Decode() - retrieve Request["sth"] to do the process, putting on the web.
I wonder if there is any mechanism like HTTPModule to help us HtmlEncode() all the items in a Http request to avoid XSS to some extent.
Appreciate for any suggestion.
Rgds,
Ricky
The problem is not retrieving Request data without HTML-encoding. In fact that's perfectly correct. You should not encode any text until the final output stage when you spit it into an HTML page.
Trying to blanket-encode incoming parameters, whether that's HTML-encoding or SQL-encoding, is totally the wrong thing. It may hide XSS holes in your app but it does not fix them. You will still have a hole if you output content that hasn't come from parameters, or has been processed since then. Meanwhile the automatic encoding will fill your database with multiply-escaped &amp;amp;amp;amp;amp; crud.
You need to fix the output stage, that's where the problem lies.
Like bobince said, this is an output problem, not an input problem. If you can isolate where this data is being output on the page, you could create a Filter and add it to the Response object. This filter would isolate the areas that are common output and then HtmlEncode them.