The issue we're running across is that we use a screen scraper to generate non copy-and-pasteable images of web pages for users who don't have access to raw data to hamper copy-and-paste activity. We have a class that's set up to instantiate a web browser object in memory, and then it accesses the page and we render it to a bitmap that we save as a jpeg.
While we can access the page okay from the server manually, when the class attempts to access it we get an error that says we can't use allowDefinition='MachineToApplication' beyond application level. We don't have any virtual directories, we don't have multiple web.configs, and the lack of reproducibility except through this one process is intensely frustrating. Any ideas what else we can do?
What you need to do is change the "allowDefinition" setting in your applicationHost.config file. That setting determines the level where it can be set, the options are as follows:
[MachineOnly|MachineToApplication|AppHostOnly|Everywhere]
If you open it up to everywhere you should be good to go. If you need to do this via command line on server 2008 you should be able to do it with the appcmd utility.
Related
I have a hyperlink to an executable like so: Run Now
I'm trying to make the download dialog box appear without the save function as it is to only run only on the user's computer.
Is there any way to manipulate the file download dialog box?
FYI: Running on Windows Server '03' - IIS.
Please no suggestions for a WCF program.
Okay I found it for anyone stumbling upon this conundrum in the future.
Add the following tag to your head section: <meta name="DownloadOptions" content="nosave" /> and the file download dialog box will not display the "save" option.
For the user to not open/run but save replace "nosave" with "noopen"
Not unless you have some control over a user's machine. If your application can run on limited resources, you might want to consider doing it in Silverlight.
IMO, having a website launching an executable is a pretty bad idea.... even worst if that website is open to the general public (not on intranet). I don't know what that app is doing but it sure is NOT, 1) cross browser, 2) cross platform, and 3) safe for your users.
If you are on intranet, you might get away with giving the full server path (on a shared drive) to the executable and change security settings on your in-house machines.
Other than that, you won't succeed in a open environment such as the Internet.
From your comments, if the user downloading the file is the issue, then there's no way to get around it, as they have to download the file in order to be able to run it.
There's any number of ways to get around whatever you could manage in browser, from proxies like Fiddler intercepting the data, or lower level things like packet sniffing. Or even simply going into the browser's temp/cache folder and copying the file out once it's running.
You could probably get around most laymen by having a program that they can download that registers a file extension with Windows. Then the file downloaded from this site would have the URL of the actual data obfuscated somehow (crypto/encoding/ROT-13/etc). The app would then go and grab the file. The initial program could even have whatever functionality provided by what you want to download, but it needs the downloaded key.
But this is moving into the area of DRM and security by obscurity. If an attacker wants your file, and it's on the Internet, they will get the file.
I made a swf that interacts with other site on the internet (which has a crossdomainfile for me).
in the main.mxml there is a definition of webservice (mx:WebService)(which is not in my domain). Therefore when loading the swf, there is a first call to crossdomainfile.xml.
I put this swf on my server so that my clients can get it.
When i connect to my server to download the swf, i expect to be asked if i want to allow the swf connect to foreign webservice domain. But i am not being asked.
Do i always need to define exception in Global Security Settings panel?
I don't want my client do define special things..
Is there a best practice for that? Why when i surfing the net other swf can do this?
I read about the FlashPlayerTrust, can i define there a website i trust my swf will connect to?
anyone knows?
You ask a bunch of questions, I'll try to explain the best I can.
The loading of the crossdomain.xml file will occur when you access the WebService located on
the remote domain; not when the swf containing the WebService call is loaded.
If a crossdomain.xml file is not there; the error is returned to the Flash Player. If you create a handler for that error, you can surpress that error from the user. IF no handler exists, I believe a run time error is displayed--but I haven't tested that.
If you want to be asked whether the swf can access the foreign domain or not; I'm pretty sure you'll have to write that code yourself.
I've never had to deal with Global Security Settings or FlashPlayerTrust in situations where I need to access a remote service.
the solution is to add headers permission to the crossdomainfile:
allow-http-request-headers-from
detailed info is in http://kb2.adobe.com/cps/403/kb403185.html
I'm creating an ASP.NET web application to schedule tasks on our server from a remote location using a .NET Wrapper for Scheduled Tasks. However, I'm stuck.
The user needs to be able to browse the file system on the server to retrieve a "file to run" for the new task that the user's creating in this application. I need to get the filepath/filename and pass it into the .NET wrapper.
I've tried using HTMLInputFile, but I haven't found a way to make that work for me.
Any help is appreciated.
Thanks
Update:
For this project, we've decided to simply list the executables in a dropdown box that would be available to users since they don't really need total access to the file system, just for security's sake.
HTMLInputFile is used to browse the client's file system and upload a file to the server. It isn't used to browse the server's file system.
You will need something quite different. You will need some server side code to display the server side folder structure to the user via the browser.
There is an example of a basic implementation of this here.
Update:
With that sample, the path that you replace "yourfolderHere" with needs to be a virtual path, rather than an absolute path. So for example "C:\Inetpub\wwwroot\uploads" won't work, but "uploads" will work.
I hope it goes without saying that there are serious security issues to think about when implementing something like this.
The HTMLInputFile will only work on the client-side machine.
You need to write a filesystem browser in ASPX/HTML that browses on the server-side.
Shouldn't be that hard to do.
You can't use the <input type="file" tag
This brings up a client-side dialog that browses the client machine.
As far as I am aware you need to create your own 'browser'.
eg You could use the My.Computer.Filesystem classes to retrieve a list of files in a folder and show those on the webpage. The user then selects the relevant file and posts a response back to the server.
You can use System.IO.Directory to get directories and files. These can be displayed in a number of ways. A simple browser / file selection should be possible in less than 50 lines of code.
Also be aware that you may need to grant extra permissions to the user that your web app runs as so the file system is accessible.
There are also various security implications around this, so don't grant access to everything unless you really need this.
Let's say we have a web site with a CF app that was written in-house.
Assume that:
Server 2003 IIS6 or 2008 IIS7 will be used
ColdFusion 8 will be used
Directory browsing is denied
SSL is required to connect
The account login process is secure (yeah I know that is a whole other
ball of wax but that concept is discussed ad nauseum on the web).
Say I have a file at https://domain.com/folder1/folder2/ with a name like picture92352.ext imagine it as a jpg or pdf or whatever. The entire path between the domain name and the file varies widely in naming structure, depth, etc. Files are not all lumped together in one folder.
The app restricts links by user such that a user would have to have access to that file to find it in the first place but as it stands now if a person knew the full URL to that file they could retrieve it without logging in to the app. It's the classic security by obscurity situation. A random person isn't likely to find a file they shouldn't get to but once someone is given access they know how to access it from another PC where their actions might not be traced back to them.
How do I restrict access to these files before someone logs in and still make them accessible to outside users after they log in? Is there a way to do it with permissions only or is the only answer to have code dynamically moving files around at the time of the request or is there some obvious step I'm not even thinking of?
Let me clarify this slightly. No matter how the file is presented on a page a user can use the browser IE, Firefox, etc to examine the URL the file comes from. If the image is a link there is always copy shortcut in the right click menu for IE and the same functionality in FF is called copy link location. If the image is displayed inline as part of the page an IE user can right click and choose properties to see the URL, in FF the same functionality is present to see properties but there is an even quicker more convenient option labeled copy image location. Once a user knows the URL to a file if the location or file name doesn't change they can use that URL without authenticating in the CF app.
If I change the NTFS/share permissions so that IUSR can't see the content then my CF app and IIS can't push it. What strategy do I use to provide the file in the CF app that doesn't leave this hole open?
You could write a CFM page that serves up the images. Then you just make sure they are authenticated inside the CFM.
<!-- something like this -->
http://localhost/GetFile.cfm?file=foobar.jpg
In GetFile.cfm, you would do something like:
<!-- the filename part is what the browser will pre-popualate the file name in the download dialog as -->
<CFHEADER name="Content-disposition" value="attachment;filename=picture92352.ext">
<CFCONTENT type="text/plain" file="\\fileserver\folder1\folder2\picture92352.ext">
Take a look at the various MIME types.
If you wanted to do something similar but keep a more natural URL, I think you would need to leverage the Java servlet underpinnings of ColdFusion to create a handler for any URL matching a certain pattern.
This would be a question for anyone who has code in the App_Code folder and uses a hardware load balancer. Its true the hardware load balancer could be set to sticky sessions to solve the issue, but in a perfect world, I would like the feature turned off.
When a file in the App_Code folder, and the site is not pre-compiled iis will generate random file names for these files.
server1 "/ajax/SomeControl, App_Code.tjazq3hb.ashx"
server2 "/ajax/SomeControl, App_Code.wzp3akyu.ashx"
So when a user posts the page and gets transfered to the other server nothing works.
Does anyone have a solution for this? I could change to a pre-compiled web-site, but we would lose the ability for our QA department to just promote the changed files.
Do you have the <machinekey> node on both servers set to the same value?
You can override the machine.config file in web.config to set this. This needs to match otherwise you can get strange situations like this.
Does your load balancer supports sticky sessions? With this on, the balancer will route the same IP to the same server over and over within a certain time window. This way, all requests (AJAX or otherwise) from one client would always hit the same server in the cluster/farm.
Ok, first things first... the MachineKey thing is true. That should absolutely be set to the same on all of the load balanced machines. I don't remember everything it affects, but do it anyway.
Second, go ahead and precompile the site. You can actually still push out new versions, whenever there is a .cs file for a page that page gets recompiled. What gets tricky is the app_code files which get compiled into a single dll. However, if a change is made in there, you can upload the new dll and again everything should be fine.
To make things even easier, enable the "Used fixed naming and single page assemblies" option. This will ensure things have the same name on each compilation, so you just test and then replace the changed .dll files.
All of that said, you shouldn't be having an issue as is. The request goes to IIS, which just serves up the page and compiles as needed. If the code behind is different on each machine it really shouldn't matter, the code is the same and that machine will reference it's own code. The actual request/postback doesn't know or care about any of that. Everything I said above should help simplify things, but it should be working anyway... so it's probably a machinekey issue.
You could move whatever is in your app_code to an external class library if your QA dept can promote that entire library. I think you are stuck with sticky sessions if you can't find a convenient or tolerable way to switch to a pre-compiled site.
If it's a hardware load balancer, you shouldn't have an issue, because all that is known there is the request URL, in which the server would compile the requested page and serve it.
the only issue i can think of that you might have is with session and view state.
Its true the hardware load balancer could be set to sticky sessions to solve the issue, but in a perfect world, I would like the feature turned off.
It appears that the is only for ViewState encryption. It doesn't affect the file names for auto compiled assemblies.
I think asp.net model has quite a bit dependency for encryption and machine specific storage, so I am not sure if it works to avoid sticky IP for session.
I don't know about ASP.NET AJAX (I use MonoRail NJS approach instead), but session state could be an issue for you.
You have to make sure session states are serializable, and don't use InMemory session. You probably need to run ASP.NET Session State Server to make sure the whole frontend farm are using the same session storage. In such case session has to be perfectly serializable (thats why no object in session is preferred, you have to always use ID, and I bet MS stick on this limitation when they do AJAX library development)