I am wondering are there any standard mechanisms available to protect the asp.net asp code in the client browser ? I found some references to Windows script encoders. Question is, are these script encoders encodes both aspx and code behind source ? If aspx is encoded with the Windows script encoders then how client browsers can decode it? Are they aware of the encoding algorithms ?
Or can we control the client browsers ( IE, Firefox, Chrome etc) to disable the view source option in the Tasks Menu when web site a loaded in them?
Any pointers will be appreciated.
The HTML code generated on a webpage is by definition public. It has to be accessible to the browser for it to be able to render the page properly. You will not find a reliable solution to hide the view source option in browsers.
To explain the basics a little bit :
When you create a page, you write markup in your .aspx file and some c# source code in the .aspx.cs file. The c# code is the server side code, which means that it is executed on the server (as opposed to, say, javascript which is executed directly in the client's browser -- client side).
When a page request is executed, the ASP.NET engine executes the server side code, and also executes the asp tags that you wrote in the .aspx page (for example : <asp:Button runat='server'... /> . It then spits out HTML code (this is a very simplified version of what actually happens).
The client's browser only ever gets the HTML (and it will not see the C# code nor any of asp markup code which is used to generate your page).
As I said before, the HTML generated is, and will always be public. There is nothing you can do to reliably hide it.
Server-side code (ie. code in code-behind pages, controllers, helpers, <% code nuggets %>, etc) will of course never be visible to a web client.
Your aspx or view pages (ie. .aspx, .cshtml, .vbhtml) files will also not be visible to web clients unless you have a signficiant security vulnerability, but the HTML generated by said files will be, along with any outputted or referenced JavaScript.
If the client couldn't read the HTML or JavaScript, how would the web browser be able to parse it?
Here's a question about obfuscating JavaScript, which will at least hinder but not completely remove a user's ability to view your source: How can I obfuscate (protect) JavaScript?
Similarly, one could theoretically obfuscate outputted HTML as well, but it could also be likely be reversed with some work.
It is impossible for the user to see your server-side (C#) source.
It is impossible to stop the user from seeing your client-side (HTML & Javascript) source.
In terms of javascript - the only thing you can do is obfuscate it to an extent that makes it worthless for someone to try to understand.
None of the code behind code is sent down to the client, only the rendered HTML.
there is no way to completely remove the ability for a client to view the source of your HTML. The only thing you can do is to obfuscate your HTML to make it harder for them to tell what they're looking at.
There are many libraries out there for obfuscating HTML in .net if you do a google search.
I'm confused really, but...
If you are on about the ASP.NET markup, you need not worry as any request to an ASP.NET page will cause the page to be compiled (if it hasn't already been, or isn't cached) which renders the page content as HTML.
If you are worried about people navigating to your code behind (e.g. mysite.com/SomePage.aspx.cs), you need not worry, as ASP.NET will not serve that content [unless the standard configuration has been changed].
If you are worried about people accessing your code through FTP, then I would suggest you change your compilation method and not deploy the source.
Am I missing anything?
Related
I've read through some of the questions here and my understanding is that this is true. Could someone confirm that visitors to an ASP.NET website can actually download the aspx files in their original format? Just like with the css files, etc. Thanks.
Clarification: Please be patient with me. I am newbie and just want to make sure I understand. I know that using Dreamweaver, a person can just download almost all the source files from a website. At least that what could be done some years ago with many websites. He would just change a few text contents and have a similar website like the original with all the original design, images, etc.
So if he can do the same with an asp.net site: downloading all the files, he can look at the aspx file and see what the code does. I am not talking about him executing the page and do the view source command. This file would naturally be processed by the server and doesn't expose source code.
This is one of the reasons why code behind is recommended because the code can be compiled and the source is not uploaded to the site. Only the dll is uploaded and minimum logic is exposed through the aspx file.
No, they can't. The ASPX page contains server-side code that is executed, well, by the server, and ends up containing plain HTML that the client browser can understand.
When IIS receives a GET request for an ASPX page, the ASP.NET handler kicks in and returns the processed HTML. So unless IIS is misconfigured, that is not possible.
No. Visitors cannot see your business logic.
If that were the case the markup asp:TextBox wont get rendered as input type='text'
Also, if that were the case we would be seeing code snippets of sites written using scripting languages like PHP or Classic ASP
in newbie's term:
No, the server won't give you ASPX and code behind files, these are files that don't mean anything to the end-user/visitor/browsers. These codes are processed on the server, and what you get is only a bunch of HTML code, javascripts, css, images, etc. which browsers can render.
If you try to "download" (by accessing them through your browser) .ASPX, .CS, and WEB.CONFIG files to see the actual source code, well you simply can't.
we are creating a custom content management and out portal page is bit bulky it is about 60Kb without images.
and during loading the page in some browser we can see some parts of site load faster than the other parts of the site where as we want to indicate (or instruct the web server) to load some of the areas first then load rest of the page.
is there any particulat setting in IIS for is there any particular method in classic asp for doing that?
also I have the same question in asp.net.
best regards.
I don't believe there is a built in way to describe which parts of a page load first in either ASP or ASP.Net. It really isn't a server decision - depends on how your browser parses the page and then requests the additional resources (or renders the existing ones).
You could potentially use AJAX and build in the order each section loads either as a state engine or by chaining. Seems to be pretty complicated for the benefit.
If you just don't want the user to see anything until the entire page loads you can control that from code using buffering. In classic ASP you use Response.Buffer and Response.Flush so the server doesn't start returning HTML until the whole page is ready - it will keep parts of the page from loading (the server won't stream results). I assume ASP.Net has a similar/identical method for buffering. Note that you can't pick sections of code with buffering but you can send only portions (top down) at a time.
I've been doing the html and css for a site, sending it off to a guy to implement in a web server. I get a call from the designer freaking out about the progress, saying the clients aren't happy. He wants me to personally integrate my css with what's on the site. The site is done in ASP.net, time is short, and I'm a little in over my head. I have an understanding of how php works, but have never worked extensively with it.
Looking at the stuff on the ftp, I can't even find equivalent of the index.html file (I know that when I go to the site itself, there is nothing after the base url, i.e., www.site.com/ brings me to the homepage.)
Can anyone give me a few tips or links as to what I am to do with this, or where to even being navigating this site?
EDIT: It's -not- a .Net Web Application, from the looks of it.
ASP.Net can be run in a compiled or a scripted environment. It is important to understand which environment your client has. If it is completely scripted, then you are likely looking for the default.aspx file and it's contents. If it is a compiled environment, you may be in for a ride. A compiled site may incorporate "master pages" as a templating engine, and then you'll need to apply your html/css modifications in several places.
You should start with the default.aspx page if there is one. Look for master page directives (it'll be named something like masterpage.master). If there isn't one, then you're in luck you'll just need to implement your changes on a page by page basis. The aspx page will be in a templated xml format so avoid touching tags that involve touching
If you are making changes to divs and structures of that nature, you may need to modify the CssClass attribute of the controls. I would recommend however that you make a back up, give it a shot, and under no circumstances attempt to do something that you aren't really ready to do. You will only anger the client and ruin your rep. It may actually be prudent to contact an actual ASP.Net developer to analyze the files separately and determine what you need to do.
I suggest that you read the Wikipedia article about ASP.NET to get familiarized with it as it summarizes the basic building structures.
Then, just to get you started: take a look at the more recent ASP.NET MVC (Model-View-Controller) paradigm. There's also development in what is called ASP.NET WebForms.
For example: when you go to www.site.com/ (known as friendly URLs) it may be redirecting you to an action method inside a controller. It's called routing. There's also URL rewrite.
In the MVC world a Controller can send/redirect the user to a specific View/Page.
A View (.aspx form/page) that contais HTML markup and CSS on the server side is basically an HTML page (.htm) page that'll be rendered on the client side.
I'm not sure how to test this question. I have an ASP.NET page for which performance is a big issue. At the same time, most of the content is static. In fact, all of the content is static at the moment. The content resides within a file extension of .aspx.
I am considering adding some functionality that would require dynamic code on the server side.
My question is, if a .aspx page does not contain any server-side code or runat="server" attributes, does anything .NET related get started? Alternatively, if a single line of server code were added to a Page_Load event handler, would this introduce a bunch of overhead like starting up the .NET runtime and such? How big of a performance penalty is it to add server code?
Thank you,
If you have a .Net application pool (and if you're serving .aspx pages, you do), the ASP.Net processor has to start up and compile the app before the first request to your page by any user. So any startup code you're worried about is already running.
If you already has .aspx pages, then you are already executing ASP .NET, and the pages are getting compiled in the background.
In that case, there will be no performance penalty in adding code, other than executing the code in question, of course.
Why don't you try it and benchmark it? An aspx page with "static" content will still get compiled. If performance is an issue, you can consider caching if appropriate.
My asp.net 2.0 web site generates text files. Sometimes these files can get quite large. Under most cases the files are presented to the user, and approved without modification. However there are times when the end-user has to make changes to these files and submit the changed version back to the system.
Currently, when a file needs to be changed, I load the text into a textbox control, and I rewrite the file on postback. However I'm running into problems with OutOfMemory exceptions, invalid viewstate, etc.... These problems only occur when the file generated is large.
I beginning to think that I need another strategy for editing these files, but I'm at a loss as to which direction to take. Is there an ACTIVEX control that would serve me better? Should I abandon server side controls for this interaction and just deal with plain vanilla http posts?
Thanks in advance.
I am not sure about an activeX control, but you could use Silverlight. Thsi would allow you to stream the file to th Silverlight control, and then it could be edited on the clints machine, and when they are done, the chnages are sent back and stored by the server.
However, you will need to have .Net 3.5 on the server and make some changes to the web.config inorder to build against the 3.5 framework. If this is not acceptable, but you like the idea of doing stuff on the client side, you can also try using flash.
One suggestion to consider would be an ajax call to a pagemethod that way you could just post the text file to the server without posting the whole page and the associated viewstate.
Can you break up the text files into sections and allow the users to submit changes one section at a time?