It is not uncommon for our intranet web applications to link to publications, documents, or other resources from our shared network file servers.
In the past, we've had little trouble fashioning links such as the following:
file://fileserver1/folderofgoodies/rules.pdf
\\fileserver1\folderofgoodies\rules.pdf
The reason we had no trouble is because everyone in the building uses IE6 or IE7 (very few have IE8). Both styles of URLs worked fine in Microsoft browsers it seems.
But if you try clicking such links in other browsers, specifically Firefox, nothing happens!
On a new intranet web app I'm developing I've been attempting to ensure cross-browser support, but any links to local computer or local network resources seem to be ignored in at least Firefox 3.5.3, though I admit I haven't yet checked other browsers.
Is there any way I can change the way I link to said files so that browsers like Firefox will accept them? I cannot do anything that requires installing scripts, software, extensions, or any other solution on a per-user/per-computer basis.
I realize the suppression of said links is a security thing, but these links would be originating from only trusted local intranet locations, so...
If this is intranet, you can build a little helper server/page/webservice/whatever to which you will link and pass file name as parameter:
http://server/getlocalfile?path=file://fileserver1/folderofgoodies/rules.pdf
And you will benefit from extended security, by the way.
I think your only option is reconfiguring Firefox, but unfortunately you said you can't do that.
You could just map the file server path as a virtual directory into your intranet site and link via http.
Mozilla applications block links to local files. The only way is to install plugin(s) to Firefox. This link describes some of them.
Related
We are looking at transferring our web-based app from Naurtech CETerm to Rhomobile. We can change javascript functions/meta tags to use the methods of Rhomobile instead of CETerm, but due to the poor hardware performance of our devices the slow down caused by the overhead of loading jQuery and other files is significant. (Prior to this we had no requirement for jQuery, although it would have been nice to have it). We also now need the rhoapi javascript which is significant.
Is there a way to include these "framework" javascript files in the Rhomobile container app and have them available to all pages loaded without them needing to be re-parsed on each page load?
It is currently a web based app loaded using something like the following in our rhoconfig.txt file as opposed to a local file:
start_path = 'http://xxxxxx.co.uk/login.php'
My current understanding is that this means the app/layout.erb file cannot be used to solve this problem?
Thanks
More than RhoMobile Suite (and it's RhoElements enterprise device framework) you can take a look at Zebra Technologies' Enterprise Browser that is intended to be used as a stand-alone industrial browser, targeting Windows Mobile/Windows CE and Android devices manufactured by Motorola Solutions (now Zebra Technologies).
On "not too old" Windows CE/ Windows Mobile devices Zebra's Enterprise Browser uses a webkit derived HTML5 capable renderer engine so, to answer your question, you can use HTML5 application cache to download the JavaScript libraries only if there's an update, in this way you can remove any network delay.
I've seen some project using giant JavaScript files (well above 1MB compressed) on old WinCE 6.0 devices, the startup time is clearly the biggest problem, with the risk to look at a white page for 5-7s. This can be alleviated with an async loader and a splash screen. It's not going to make your page faster, but the user will know what is going on.
You can find more information about Enterprise Browser on Zebra Technologies developer website, the Launchpad, inside Enterprise Browser area.
If you build your custom RhoMobile web-app container with the idea to use in server pages, local resources, you can hit some issues around cross-site scripting prevention policies.
Tricky one.
Browser Security says "No".
Scenario:
Forms and Templates are used throughout the business, this can be word, excel or pdfs files.
We have a intranet system and I would like to offer users the ability to open files via this way. (not download).
However the browser has other ideas (which I understand why), however is their a work around?
to achieve this?
I have looked around the web and have found that appending #page=?? to the end of a PDF link will automatically take the visitor to that specific page in the PDF file.
I was wondering if this is still best practice as it doesn't seem to be working for me (Chrome on Windows 7). Also, all the articles I have found so far date back to 2006-2008, have things changed recently?
This is still valid code but it may require that some version of Acrobat (Reader, Pro, etc) be installed as a plugin on the browser in order for it to work as expected. Since multiple commonly-used browsers now have a built-in reader (Chrome, Safari for iOS are the big two that come to mind) support for direct page linking is somewhat spotty now. You can still do it...the worst case scenario is that the PDF just opens to the first page for those users but I would advise to just leave off the direct page link. If the page is that important, extract it to a separate PDF and link to that.
It's pretty much known that publishing to a remote location using VS2008 is a an exercise of great patience and faith.
As long as a 'publish' begins (using VS2008, publishing an MVC site), that site might be down from the first file that is successfully transferred. The problem being that unreliable internet access, or interesting error messages () can break the site, and require restarting.
It's understood that there is little to do from the VS2008 end. The question then:
What strategy can I use to ensure that there is an acceptable user experience during the 'downtime'? (e.g. "This site is currently under maintenance...")
A lovely feature of ASP.NET/IIS is that if you place a file named app_offline.htm in the root of the web application, all requests will redirect to that file. This would include requests for images, stylesheets, scripts, etc.. so you'll need to condense all media for the page into the page itself.
In fact, while Visual Studio is in the process of publishing your web application, it will place this file in the root of the application and remove it when the publish is complete. While Visual Studio doesn't allow you to customize the contents of its app_offline.htm, you can take the application offline yourself simply by uploading that page.
I am trying to get a demo site for a client setup. This is the 1st application my company is doing in MVC.NET, so I get to experience all the new things to find out (and all the headaches it'll cause).
Anyway, the site works fine locally (localhost) and on the server inside our domain. External users not on the domain however, only get 404 errors. I've tried several different settings/ config options I've found on this site, but nothing is working. I don't know if it's a web.config issue or an IIS issue, or even simply a permissions issue (though it has all the same permissions as the other sites we run with Web Forms).
IIS: v7 in intergrated mode.
Windows Server Web
Well, because you received a 404, the server is being reached okay which is a good sign. (Dealing with firewall issues at a company is always a lot of fun.)
A common problem for something like this is the use of virtual directories to host the website. For example, if the address to your site is http://example.com/MySite/, in MVC that would translate to: /MySite/View/Index.aspx. HOWEVER...if you are using virtual folders, /MySite/ may instead point to another spot on the server (e.g. C:\WebSites\MySite). If you are indeed using virtual paths, make sure you have your files stored at the correct path.
There is a troubleshooting tutorial here: http://support.microsoft.com/kb/248033
thanks for the answers everyone. Turns out it was something with our DNS routing setup with the sub-domains. It was getting rerouted to a place that didn't exist. Our IT guy finally got around to fixing it (ugh!)