Here is an example of the start of an XML file we build, note that is is Accessing "CCD.xsl" for the style sheet.
'<?xml version="1.0"?>'
'<?xml-stylesheet type="text/xsl" href="' + 'C:\CDA\Schemas\CCD.xsl"?>'
'<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"'
Anytime this xml loaded into a TWebBrowser from a remote user accessing the server they get the following error
"Access is denied. Error processing resource 'file:///C:/CDA/Schemas/CCD.xsl'."
WebBrowser1.Navigate(TempFileName); //TempFileName = C:\data\CCR_Record_3336557.xml
Any Ideas on how this could be resolved?
If you need additional information let me know..
Thanks, appreciate the help.
You have two problems, both stemming from the fact that the XSL reference is to a local file on the C drive.
Problem #1 (the one giving you the error) is that your browser is blocking attempts to access local file system resources from a remotely-downloaded XML file. So the browser throws a security error when trying to render that XML file. That's the immediate error you're seeing. Adjusting security settings or changing browsers won't solve your problem because of problem #2.
Problem #2 is that your client presumably doesn't have an XSL file on their local hard drive at C:\CDA\Schemas\CCD.xsl. It's on the C drive of the remote server. You can't just put it on a network share because of problem #1, so you'll need to serve it through the same mechanism you serve the XML file. Then change your URI for the XSL file to something like http://myserver/schemas/ccd.xsl.
Related
I've been playing with Saxon-CE_1.1 over the last few days and have managed to create a little application that allows users to classify pictures according to a data dictionary using a select dialog. All was going really well until I tried to use the result-document() function in it's "classic" way, to create a new file in the file system containing the choices the user has made.
XML Quire is returing with a severe error stating:
XpathException in mode: '{http:saxonica.com/ns/interactiveXSLT}onclick' event: [object MouseEvent]: Expected '?select=' ir '#' at start of result document href found "filename.xml
This error seems, to me, to be stating that I must pipe the results back into the HTML using # or ?select/
Is it still possible to create "external" output using SaxonCE? If so how can I accomplish the task.
Until recently it has not been possible to read or write files in the local client machine from Javascript code running in the browser, and if Javascript can't do it, then Saxon-CE can't do it either.
This may change soon with the HTML5 FileSystem API, but as far as I'm aware support for this is still very patchy. When it appears to be more stable and widespread, we can certainly look at implementing both doc() and xsl:result-document to access local filestore (or indeed, implementing the EXPath file module).
Basically I get an error every time I try open or get this txt file via url. However when I change the extension to css it opens fine. I have tried re-uploading and it makes no difference.
Try for yourself:
http://seanbingley.comyr.com/DrKruseSite/articles.txt
http://seanbingley.comyr.com/DrKruseSite/articles.css
Thanks in advance.
Edit:
I should probably state that I am not bothered about actually opening it in a browser. I need to read data from it for my website. However I cannot read the data if it keeps giving me 404.
Also when opening the txt file locally in a browser it works fine. It's just when I try to open the same file from the server it goes wrong.
You have to add a mime-type on IIS so it can read it.
Okay so the hosting site (000webhost) does not allow txt files on free accounts.
Ok I know Maximo 5.2 is horribly outdated but currently I just want to get the attachment working. So here is the situation:
I have an old server (running 2000) with a folder being shared on the network with the name of F$. I have tried that the attachment uploading functionality works fine: users can attach any file to a work order and that file will be copied into a specified folder in the F: drive of the server. But when I try to access to that file from the client side -- that is, click on the link within the work order (from attachment tab in Maximo webapp) in order to view the attachment -- I get a 404 response. So in a way it's like I am able to write to the server but somehow I can't read or download it from the client side.
UPDATE:
I found out that after you've uploaded a file to the server, it can be accessed from the link http://servername:port/doclinks/drawings/filename from any other client side desktop in the browser. However within the Maximo web app, the webpage javascript automatically parse the link as http://servername/f$/MAXIMO/doclinks/drawings/filename -- It returns redundant part and withno port number. Is this returned link configurable through settings or do I have to dig into the JSP?
You need to set up virtual directory mapping on weblogic
http://docs.oracle.com/cd/E11035_01/wls100/webapp/weblogic_xml.html
The files are on the server. You just to correctly map the doclinks root on the file system to make it accessible to the web. You are getting a 404 error because the mapping is wrong.
In c:\maximo\applications\maximo\maximouiweb\webmodule\WEB-INF look for weblogic.xml
Add an entry:
<virtual-directory-mapping>
<local-path>/apps/maximo/</local-path>
<url-pattern>/doclinks/*</url-pattern>
</virtual-directory-mapping>
The entry above sits between <weblogic-web-app> and </weblogic-web-app>
The above example would mean your doclinks directory on the server is /apps/maximo/doclinks/
You would need to edit weblogic.xml, redeploy your maximo.ear along with your doclinks.
Because you are getting http://servername/f$/MAXIMO/doclinks/drawings/filename, particularly the f$/MAXIMO part, it tells me your F<PATH>\\MAXIMO\\doclinks = http://servername:port/doclinks mapping in your doclinks.properties is not correct. If you are on the Maximo host, via remote desktop or whatever, and you open Windows Explorer, what do you need to put in the address bar to access the attached documents folder? You said it's on F$, but F<PATH> in your properties file will translate into F:, not F$. So, you need to change your doclinks.properties
from: F<PATH>\\MAXIMO\\doclinks = http://servername:port/doclinks
to: \\\\servername\\F$\\MAXIMO\\doclinks = http://servername:port/doclinks
I´m making a web application in MVC, I have a view where I select a file from my pc directory (like opendialog form in windows applications), bootstrap´s fileupload gets the file name but I want to know his physical path to. Because I want to save it in my data base (where file come from).
Anybody can help me??
Thank you in advance!
You can't, this information is never sent to the server for obvious security reasons. Only the filename is sent to the server. So you cannot store the physical path where the file originated from the client machine on your server.
When you upload a file via a web browser, the actual file path is not supplied. This is seen as being a security feature.
There is no way to circumvent this using pure HTML. Some people get around it by using a plugin such as Flash or Silverlight to upload the file, but I recommend living with this feature if you can.
I have an ASP.NET MVC website that works in tandem with a Windows Service that processes file uploads. For easy maintenance of the site, I'd like the log file for the Windows Service to be accessible (to me, only) via the website, so that I can hit http://myserver/logs/myservice to view the contents of the log file. How can I do that?
At a guess, I could either have the service write its log file in a "Logs" folder at the top level of the site, or I could leave it where it is and set up a virtual directory to point to it. Which of these is better - or is there another, better way?
Wherever the file is stored, I can see that there's going to be another problem. I tried out the first option (Logs folder in my website), but when I try to access the file via HTTP I get an error:
The process cannot access the file 'foo' because it is being used by another process.
Now, I know from experience that my service keeps the file locked for writing while it's running, but that I can still open the file in Notepad to view the current contents. (I'm surprised that IIS insists on write access, if that's what's happening).
How can I get around that? Do I really have to write a handler to read the file and serve it to the browser myself? Or can I fix this with configuration or somesuch?
PS. I'm using IIS7 if that helps.
Unfortunately I'm afraid you'll have to write a handler that will open the file, and return it to the client.
I've written an IIS Manager extension that displays server log files, and what I've noticed that even the simple
System.IO.File.OpenRead("")
can still run in the same problem, and return the same error.. It was kind of confusing.
In the end I used
System.IO.File.Open("", FileMode.Open, FileAccess.Read, FileShare.ReadWrite)
and I could easily open the file while the server was writing logs to it :)
I think the virtual directory is an "okay" solution, if you add the directory (application) with READ ONLY rights + perhaps "BROWSE directory" too (so you can see the folder contents rendered by the IIS).
(But once you do that, you should consider that you also anonymous access to that folder - unless you enable authentication, so watch out for "secret" contents of the logfiles that you might expose? just a thought.)
Another approach, I prefer myself, is to make a MVC/ASP.NET page that does the lookup in the folder by normal code, so that you 100% can filter whatever data is shown in the HTML.
You can open the files as TextStream's and in Read Only mode.
If it's a problem to gain access to the logfolder, I would use the virtual directory with READ ONLY access and then program something that renders the logfiles as HTML on my screen and with my detail levels. Perhaps even add some sort of "login" first. But it all depends on your security levels and contents of logfiles.
is this meaningfull to you? if not, please explain more, as I've been through this thought a few times already for similar situations.