Byte array output as an Image - asp.net

I know it is be possible to do this:
<asp:Image runat="server" ImageUrl="~/MyImageHandler.ashx?imageid=2" />
...but I have a case where the byte array data is only available to the Page (ie, not available in the session, and cannot be referenced by an id) so I can't point the ImageUrl to a different page.
Is there a way of giving an asp:Image the byte array to render as an Image?

The major hurtle you're going to have to deal with is that an <asp:Image/> element gets rendered as a regular <img />, which needs a src attribute that points at a URL.
That being the case, I see two hairy alternatives:
Use the technique described here to embed your image encoded in Base64 in the src attribute. Note that this does not work with Internet Explorer.
Embed your Base64-encoded image into the page as a hidden <input /> element. You could then use JavaScript to POST that data back to the server, which would just send it back to the browser using Response.Write() (being sure to set the Content-Type appropriately, of course).

The only decent solution to this is to put the byte array in session. If you're concerned about uniqueness (multiple people getting each other's byte arrays), use a random GUID as the key.

Related

POST rendered text by Razor in ASP.NET MVC to server

I have a situation where I make a with some Razor. This is pretty standard, so imagine something like:
<div>
<strong>Undertegnede myndige skyldner</strong>:<br /><br />
#Model.ContractText.DebtorName, #Model.ContractText.DebtorFullAddress
#foreach (var reminder in Model.DemandStructure.ReminderFees_Lines)
{
#reminder.Label #: #reminder.Amount.ToCurrency()<br />
}
</div>
This becomes a nice piece of text.
What I want to do, is to POST this generated text, and store it on the server.
Possible solutions
Now, I could of course just generate this string on the server, but then I would loose the nice formatting of Razor.
I could use some templating language - but I am not familiar with anything that is easy and solves my problem to use on the server side?
Maybe it makes sense to wrap this in some kind of input field so it's POST-ed to server?
Does anyone have a simple and smart solution for how to POST a generated text-string to the server?
Do you mean post the text to the server in relation to a user action on the page?
If not, certainly do it server-side instead, and even in that case while yes, you potentially could wrap it in a form element (or probably wrap a copy of the text in for example a hidden element) and that will be submitted with any form submits - you probably shouldn't do this for a number of reasons;
The user will be able to edit the text before it is send to the server, and it looks like they shouldn't be able to, as then they could change the Amount value before it is stored
It will be hard to encode the newlines (they are br elements in your HTML but these don't post correctly to a newline in a string so you would have to convert them, or use a textarea instead)
It generates unnecessary network traffic.
What you should probably do is simply store it on the server-side code, using a format string to create the same resultant text;
var theText = $"Undertegnede myndige skyldner:{Envionment.NewLine}{Envionment.NewLine}{Model.ContractText.DebtorName}, {Model.ContractText.DebtorFullAddress}
{String.Join(Environment.NewLine, Model.DemandStructure.ReminderFees_Lines})";

Can not display base64 encoded images in an HTML fragment in WinJS app

I'm writing a WinJS app that takes an HTML fragment the user has copied to the clipboard, replaces their
Later, when I go to display the .html, I create an iFrame element (using jQuery $(''), and attempt to source the .html into it, and get the following error
0x800c001c - JavaScript runtime error: Unable to add dynamic content. A script attempted to inject dynamic content, or elements previously modified dynamically, that might be unsafe. For example, using the innerHTML property to add script or malformed HTML will generate this exception. Use the toStaticHTML method to filter dynamic content, or explicitly create elements and attributes with a method such as createElement. For more information, see http://go.microsoft.com/fwlink/?LinkID=247104.
I don't get the exception if I don't base64 encoded the images, i.e. leave them intact and can display iframes on the page with the page showing images.
If I take the html after subbing the urls for base64 and run it through toStaticHTML, it removes the src= attribute completely from the tags.
I know the .html with the encoded pngs is right b/c I can open it in Chrome and it displays fine.
My question is I'm trying to figure out why it strips the src= attributes from the tags and how to fix it, for instance, creating the iframe without using jquery and some MS voodoo, or a different technique to sanitize the HTML?
So, a solution I discovered (not 100% convinced it the best and am still looking for something a little less M$ specific) is the MS Webview
http://msdn.microsoft.com/en-us/library/windows/apps/bg182879.aspx#WebView
I use some code like below (where content is the html string with base64 encoded images)
var loadHtmlSuccess = function (content) {
var webview = document.createElement("x-ms-webview");
webview.navigateToString(content);
assetItem.append(webview);
}
I believe you want to use execUnsafeLocalFunction. For example:
var target = document.getElementById('targetDIV');
MSApp.execUnsafeLocalFunction(function () {
target.innerHTML = content}
);

Do I need to html-encode title attributes (tooltips)?

In my markup I am using HTML title attributes which I set by the Tooltip property of various ASP.NET controls like an asp:Label. The content of those titles come from a database and I use data binding syntax, for instance:
<asp:Label ID="PersonLabel" runat="server"
Text='<%# HttpUtility.HtmlEncode(Eval("PersonShortName")) %>'
ToolTip='<%# HttpUtility.HtmlEncode(Eval("PersonFullName")) %>' />
Now, tooltips seem to be displayed as plain text on Windows and in the browsers I have tested. So the HTML-encoding is not what I really want and I am inclined to remove the encoding.
Can this be dangerous in any way if the database fields may contain script tags for example? My question is basically: Is it always guaranteed that HTML-title attributes are displayed as plain text? Are they always displayed as tooltips at all, or is it possible that some browsers (or OSs) display them in another way and allow and render HTML content in the title attributes?
Edit:
Looking at some of the answers it seems I didn't phrase my question well, so here are some additions:
If I have in the code snippet above a PersonShortName of "PM" in my database and as the PersonFullName a name with non-ASCII characters in it like Umlauts in "Peter Müller" the browser displays in the tooltip Peter Müller when I apply HttpUtility.HtmlEncode like in the code example - which is ugly.
I've also tested a simple HTML fragment like:
<span title="<script>alert('Evil script')</script>" >Hello</span>
The script in the title attribute didn't run in a browser with enabled Javascript (tested with Firefox), instead it was displayed in the tooltip as plain text. Therefore my guess was that title attributes are always rendered as plain text.
But as Felipe Alsacreations answered below there exist "rich tooltip plugins" which may render the title attribute as HTML. So in this case encoding is a good thing. But how can I know that?
Perhaps HttpUtility.HtmlEncode isn't the right solution and I have to filter only HTML tags but not encode simple special characters to make sure that the plain text is displayed correctly and to protect "rich HTML tooltips" at the same time. But it looks like a costly work - only for a simple tooltip.
Always sanitize output to the browser.
If a value like "><script>blabla</script> is inserted as a value for your fields, a user can essentially take over your entire site. It will probably make a mess when it comes to validation and correct code, but the script will still be run.
So to answer your question: No, it is not guaranteed that HTML-title attributes are displayed as plain text if the user knows what he/she is doing.
Beside security reasons:
Title attributes should always be plain text but certain JS plugins misuse them to display 'rich' tooltips (i.e. HTML code with bold text, emphasis, links and so on).
As for browsers and AFAIK they are displayed as plain text and tooltips, never displayed to those who use tabbed navigation (keyboard) and scren readers give to their users (blind and partially sighted people) many options, like reading the longest between link title and its text or always title or never ...
Surprisingly, still, no right answer in 5 years. The answer is: yes, you need to encode the title attribute, but not everything that is encoded in the innerText of the element.
The proper way to do it in asp.net if you do your own markup is:
string markup = string.Format("<div class='myClass' title='{0}'>{1}</div>",
System.Web.HttpUtility.HtmlAttributeEncode(myText),
System.Web.HttpUtility.HtmlEncode(myText));
The above will set both innerText and title of the div to myText, which is customary for elements that may contain long text but are constrained in width (as I believe the question implies).
The ToolTip property of a ASP.NET control will auto encode the value on output/rendering.
This means it is safe to set the tooltip to plain text as the page will sanitize the text on rendering.
Label1.ToolTip = "Some encoded text < Tag >"
Renders HTML output as:
<span title="Some encoded text < Tag >"></span>
If you need to use text that is already encoded, you can set the title attribute instead. The title attribute will not be automatically encoded on rendering:
Label1.Attributes("title") = "Some encoded text < Tag >"
Renders HTML output as:
<span title="Some encoded text < Tag >"></span>
Another point:
Who cares how the title attribute is rendered by a browser, when it is the presence of malicious strings in the source code that could present an issue?
It doesn't matter how it is displayed, the question is: how does it appear in the source code?
(As already stated, if you're pumping strings to the client, do something to sanitize those strings.)
I think there may be some confusion going on with this thread.
Firstly <asp:Label> is an ASP.NET Web Control. The Text and ToolTip attributes are "abstractions" of the inline content and 'title' attributes of an HTML tag respectively.
For these particular two properties Microsoft will perform the HTML Encoding for you automatically so if you set ToolTip="H&S<" then the <span> tag will be rendered as <span title="H&S<"...>. The same goes for the Text property.
NOTE: Not all properties perform automatic encoding (HTML or InnerContent properties for example)
If however you are generating HTML tags directly (Response.Write("<span...") for example) then you MUST http encode the text content and tooltip attributes content if:
Those values originate from a user / external unsanitised source or
If there is a possibility that the content may contain characters that should be escaped (& < > etc.)
Usually this means that it is safe to to:
Hardcoded content with no http characters:
Response.Write("<span title='Book Reference'>The art of zen</span>"); // SAFE
Hardcoded content with http characters that you manualle encode:
Response.Write("<span title='Book & Reference'>The art & zen</span>"); // SAFE
Dynamically sourced content:
Response.Write("<span title='"+sTitle+"'>"+sText+"</span>"); // UNSAFE
Response.Write("<span title='"+HttpUtility.HtmlEncode(sTitle)+"'>" +HttpUtility.HtmlEncode(sText)+"</span>"); // SAFE

asp.net best practice string concatenation

I am trying to find the best practice for generating and outputting html which would require a database query first to obtain the info. Currently in the aspx page I have a div with runat server:
<div runat="server" id="leaflet"></div>
Now just as a start to do a bit of testing I have a method that runs on page_load that basically does:
private void BuildLeaflet(string qnid)
{
//gets leaflet details
QueryLeafletDetails();
//return concatenated content string
leaflet.InnerHtml "<h1>" + dr["LSC Descriptor"] + "</h1>";
}
In the real solution the return is a concatenation of about 10 fields some very long as they are content.
I don't by any means think this is the best solution, but what is? A StringBuilder? Can I Write Each Part in turn to the site avoiding the concatenation in the method? Is the server div even best?
Edit: Forgot to put some of my content sections have simple (limited) html in them already such as paragraph, list... This allows me to easily produce documents for web and printing, I just use different stylesheets.
I would use <asp:Literal runat="server" enableViewState="false" id="leaflet" />. This doesn't generate any tags on the page, and doesn't stuff all the text in the ViewState.
And yes, use StringBuilder if you need to concatenate many long strings. This will be way more memory efficient.
The other solution would be to see if you can make some fixed markup on the page and put the contents of each DB field in it's own control (<asp:Literal />?).
I'd use either string.Format, if the number of fields is fixed (and relatively small), or a StringBuilder, otherwise. Readability of the code would be my guide, less so performance. You might also want to think about abstracting this out into a UserControl if you plan to reuse it. Then you could give it settable properties and build the render logic into the control to avoid repeating yourself.
Various people have benchmarked this - iirc format is fine for <4 items, simple concats for <7, stringbuilding above that.
I strongly advise against creating HTML as strings btw.

Encoded character is used instead the correct one

I have a little problem and I'm hopping that you can help me solve this annoying issue.
I need to use an iFrame in an administration panel to let users use the selection service, and in the HTML I have:
<iframe scrolling="yes" runat="server" title="Par Selection" id="iFrame"
frameborder="0" enableviewstate="true" width="100%" height="490" />
in my code-behind file I have:
iFrame.Attributes.Add("src", String.Format(
"https://www.parurval.se/urval/?username={0}&password={1}",
parSettings.GetSettings(parSettings.SettingsType.PARSelection, parSettings.SectionType.Username),
parSettings.GetSettings(parSettings.SettingsType.PARSelection, parSettings.SectionType.Password)));
The output is this:
<iframe id="tcMain_tabPARSelection_iFrame" scrolling="yes" title="Par Selection"
frameborder="0" width="100%" height="490"
src="https://www.parurval.se/urval/?username=myUsername&password=myPassword">
</iframe>
Please note the & instead & sign in the src address when passing username and password
How can I prevent this?
I tried with HttpUtility.Decode( myCompleteUrl ) but with the same achievement :(
The worst thing is, if the src code has only the address
... src="https://www.parurval.se/urval/" ...
I'm not able to input the user/pwd, I see the form and I can enter text, but it does nothing, it only refreshes the iframe inner page, doing this in a full window, works fine.
And in that administration panel I have a textbox to the user add the username and password in order that entering the Administration page, I will jump directly to the service in the iFrame so the user does not need to enter user/pwd to login every time, that is way I'm trying to add those values dynamically.
Any ideas?
Added:
If I put the correct URL address (with user and pwd) in the iFrame src attribute in the HTML side (not dynamically) all works fine :(
The presense of the & is actually correct there. Most browsers are forgiving enough not to choke on just seeing & there, but it's technically not correct.
“&” is a special character in HTML (more specifically in SGML), so encoding it is the correct thing to do. Yes, even in link URLs.
The HTML 4.01 specification states:
Authors should use "&" (ASCII decimal 38) instead of "&" to avoid confusion with the beginning of a character reference (entity reference open delimiter). Authors should also use "&" in attribute values since character references are allowed within CDATA attribute values.
So encoding the & as & is correct behavior since the interpretation of the src attribute value (CDATA data type) is described as:
CDATA is a sequence of characters from the document character set and may include character entities. User agents should interpret attribute values as follows:
Replace character entities with characters,
Ignore line feeds,
Replace each carriage return or tab with a single space.
Otherwise src attribute values like /foo?bar&sect=123 would be ambiguous as they can be interpreted either literally as /foo?bar&sect=123 or (replacing the sect entity) as /foo?bar§=123.
This seems like a case where you can take advantage of URL encoding to hide the &, bypassing XML encoding. & is U+0025, so you can encode it as %25: https://www.parurval.se/urval/?username={0}%25password={1}
You should use
HttpUtility.HtmlEncode(String.Format("https://www.parurval.se/urval/?username={0}&password={1}",
parSettings.GetSettings(parSettings.SettingsType.PARSelection, parSettings.SectionType.Username),
parSettings.GetSettings(parSettings.SettingsType.PARSelection, parSettings.SectionType.Password)));

Resources