First off if you're unaware, samba or smb == Windows file sharing, \\computer\share etc.
I have a bunch of different files on a bunch of different computers. It's mostly media and there is quite a bit of it. I'm looking into various ways of consolidating this into something more manageable.
Currently there are a few options I'm looking at, the most insane of which is some kind of samba share indexer that would generate a list of things shared on the various samba servers I tell it about and upload them to a website which could then be searched and browsed.
It's a cheap solution, OK?
Ignoring the fact that the idea is obviously a couple of methods short of a class, do you chaps know of any way to link to samba file shares in html in a cross-browser way? In windows one does \\computer\share, in linux one does smb://computer/share, neither of which work afaik from browsers that aren't also used as file managers (e.g. any browser that isn't Internet Explorer).
Some Clarifications
The computers used to access this website are a mixture of WIndows (XP) and Linux (Ubuntu) with a mixture of browsers (Opera and Firefox).
In linux entering smb://computer/share only seems to work in Nautilus (and presumably Konqueror / Dolphin for you KDE3.5/4 people). It doesn't work in Firefox or Opera (Firefox does nothing, Opera complains the URL is invalid).
I don't have a Windows box handy atm so I'm unsure if \\computer\share works in anything apart from IE (e.g. Firefox / Opera).
If you have a better idea for consolidating a bunch of random samba shares (it certainly can't get much worse than mine ;-)) it's worth knowing that there is no guarantee that any of the servers I would be wanting to index / consolidate would be up at any particular moment. Moreover, I wouldn't want the knowledge of what they have shared lost or hidden just because they weren't available. I would want to know that they share 'foo' but they are currently down.
Hmm, protocol handlers look interesting.
As Mark said, in Windows protocol handlers can be dealt with at the OS level
Protocol handlers can also be done at the browser level (which is preferred, as it is cross platform and doesn't involve installing anything).
Summary of how it works in Firefox
Summary of how it works in Opera
I'd probably just setup Apache on the SAMBA servers and let it serve the files via HTTP. That'd give you a nice autoindex default page too, and you could just wget and concatenate each index for your master list.
A couple of other thoughts:
file://server/share/file is the defacto Windows way of doing it
You can register protocol handlers in Windows, so you could register smb and redirect it to file://. I'd suspect GNOME/KDE/etc. would offer the same.
To make the links work cross platform you could look at the User Agent either in a CGI script or in JavaScript and update your URLs appropriately.
Alternatively, if you want to consolidate SMB shares you could try using Microsoft DFS (which also works with Samba).
You set up a DFS root and tell it about all the other SMB/Samba shares you have in your environment. Clients then connect to the root and see all the shares as if they were hosted on that single root machine; the root silently redirects clients to the correct system when they open a share.
Think of it as like symbolic links or a virtual file system for SMB.
It would solve your browsing problem. I'm not sure if it would solve your searching one.
Related
On an intranet site, let's say I want to link to a file on a share using UNC, at:
\\servername\foldername\filename.rtf
It seems the correct way to do this is with markup like this:
filename.rtf
That's five slashes - two for the protocol, one to indicate the root of the file system, then two more to indicate the start of the server name.
This works fine in IE7, but in Firefox 3.6 it will only work if the html is from a local file. I can't get it to work when the file comes from a web server. The link is "dead" - clicking on it does nothing.
Is there a workaround for this in Firefox? Those two browsers should be all I need to worry about for now.
Since this is obviously a feature of Firefox, not a bug, can someone explain what the benefit is to preventing this type of link?
This question has been asked at least twice before, but I was unable to find those posts before posting my own (sorry):
Open a direct file on the hard drive from firefox (file:///)
Firefox Links to local or network pages do not work
Here is a summary of answers from all three posts:
Use WebDAV — this is the best solution for me, although much more involved than I had anticipated.
Use http:// instead of file:///// — this will serve up a copy of the document that the user cannot edit and save.
Edit user.js on the client as described here — this worked for me in Firefox 3.6.15, but without access to client machines, it's not a solution.
In Firefox, use about:config, change the Security.fileuri.strict_origin_policy setting to false — this doesn't work for me in 3.6.15. Other users on [SO] have also reported that it doesn't work.
Use the locallinks Firefox extension — this sets the Security.fileuri.strict_origin_policy to true for you, and appears to have no other effect.
Read the file server-side and send it as the response — this presents the same problem as simply configuring your web server to use http://.
Browsers like Firefox refuse to open the file:// link when the parent HTML page itself is served using a different protocol like http://.
Your best bet is to configure your webserver to provide the network mapped file as a web resource so that it can be accessed by http:// from the same server instead of by file://.
Since it's unclear which webserver you're using, I can't go in detail as to how to achieve this.
In Firefox to Open File:\\\\\yourFileServer\docs\doc.txt for example you need to turn on some options in Firefox configuration:
user_pref("capability.policy.policynames", "localfilelinks");
user_pref("capability.policy.localfilelinks.sites", "http://yourServer1.companyname.com http://yourServer2.companyname.com");
user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");
As it turns out, I was unaware that Firefox had this limitation/feature. I can sympathize with the feature, as it prevents a user from unwittingly accessing the local file system. Fortunately, there are useful alternatives that can provide a similar user experience while sticking to the HTTP protocol.
One alternative to accessing content via UNC paths is to publish your content using the WebDAV protocol. Some content managements systems, such as MS SharePoint, use WebDAV to provide access to documents and pages. As far as the end-user experience is concerned, it looks and feels just like accessing network files with a UNC path; however, all file interactions are performed over HTTP.
It might require a modest change in your file access philosophy, so I suggest you read about the WebDAV protocol, configuration, and permission management as it relates to your specific server technology.
Here are a few links that may be helpful if you are interested in learning more about configuring and using WebDAV on a few leading HTTP servers:
Apache Module mod_dav
IIS 7.0 WebDAV Extension
Configuring WebDAV Server in IIS 7, 6, 5
Add your own policy, open configuration "about:config" in the location bar and add three new entries:
capability.policy.policynames MyPolicy
capability.policy.MyPolicy.sites http://localhost
capability.policy.MyPolicy.checkloaduri.enabled allAccess
Replace http://localhost with your website.
Works with Firefox 70.0.
I don't know if this will work, but give it a shot! Old article, but potentially still useful.
http://www.techlifeweb.com/firefox/2006/07/how-to-open-file-links-in-firefox-15.html
Disclaimer: This may be a better question on SuperUser, but my use
case matches SO.
I'm trying to develop an Angular app on my local computer; I'm not yet ready to set up a webserver or anything like that. I'm loading some JSON configuration files from the same directory, and I'm running into Origin Policy issues (which was expected).
I know that programs like gChat can run multiple instances with the /mutex flag (I think that's it, it's been a while since I tried that). Is there any such provision for Google Chrome? Basically, I'd like to run Chrome as my main browser for everything I do, and then open a separate instance with lowered web security for testing purposes.
Thanks!
You can bring up a development web server, serving data from the current working directory, using:
python -mSimpleHTTPServer
This doesn't directly answer your question, I know. But hopefully it's even better than a direct answer. :)
I found a solution to this - although Chrome won't let you run multiple instances, you can run Chrome and Chrome Canary side-by-side simultaneously. So now, Chrome is my main browser, and Chrome Canary (with the --disable-web-security) flag is my testing environment. So far, I haven't had any issues with discrepancies between the browsers.
Found an interesting article about "Cruftless" links (removing the "index.html" from links) but when I do that no browser shows the local pages.
http://www.nimblehost.com/blog/2012/11/why-cruftless-links-are-better/,
This is understandable, it's a 'file' url from a local machine, so what do people do to work on basic html sites offline? How do they preview them?
For example, no browser (understandably) will display this...
file:///JOBS/ABC/About/
... but this is fine...
file:///JOBS/ABC/About/index.html
?... so what do people do to get around this?
The meaning of file: URLs is, by definition, system-dependent. Normally browsers map them to files in the file system in a relatively straightforward manner.
Thus, a link with href value like file:///JOBS/ABC/About/ may or may not work, depending on system. It may fail, or it may open a generated document containing a directory (folder) listing, or it might do something else.
There is normally no need to get around this, and it is pointless to worry about SEO when dealing with local files.
This could, however, matter during site development when you work with a site locally (and perhaps test and demonstrate it locally). Then you might wish to have, say, About us so that it works locally as well as on a server, yielding About/index.html in both cases but without hard-wiring index.html in HTML markup.
I’m afraid the answer is “you can’t”. But as a workaound, you can install and use a local HTTP server, with settings similar to those that you will have on the real server. This means a little extra work (mainly downloading and installing and configuring software like XAMPP), but it also gives you important other benefits, like testing your pages locally with server-based features (to the extent that the real server is similar to the local server).
I have been curious about better ways to cross browser test than those screenshot services or maintaining my own array of VMs to VNC into. Then today I found crossbrowsertesting.com (which seems to allow you to connect from your browser via VNC to one of their machines running virtually any browser). This is really similar to a solution I had been thinking about, but veered away for a few reasons. I have two questions about this service:
if you have used the service, what are its pros/cons?
how do they get around people doing all kinds of nasty things on their VMs, since they give you a full desktop to play around in.
Bonus: how do they get around the legal issues regarding people VNC'ing into Windows and using IE when the connecting clients clearly do not own the software?
Have not used it sorry, but the standard con for a remote service is that your test site has to be accesible to the web.
You secure the desktops with the tools you get with Windows Server, the ability to lock down a user has been around for a while, although it still needs work.
Bonus: You can licence Terminal Services for multiple users, we frequently use it on our "management" servers that allow all the technical staff to log onto one server in the environment and then connect from there to the production servers. We licence it for everyone to log into at once.
Apart from not being able to access local, i.e. on company's intranet or your hard drive, web sites crossbrowsertesting.com may also have a response time issues. VNC is not a very efficient protocol and working using VNC can be a pain.
I prefer tool that allow me to install all relevant browsers on my PC, such as BrowserSeal
If Microsoft's method for using IE as a local host for HTA's then, can I use any other browser instead?
You can't.
There is a similar Mozilla project named XULRunner, but HTA only works in Internet Explorer - the two technologies aren't compatible.
To make this clear: HTA will probably not work in anything that's not IE. Yes, HTA is a browser control in a window, but it also has normal aplication privileges (i.e. filesystem access, registry, arbirary code execution etc.). When running in a browser, these privileges are denied (for good reasons - you don't want just any webpage to read your files).
So, launching the HTA in a browser will work, but any interaction with the local system will fail, which negates the whole idea. Launching a HTA in XULRunner will also fail, because XULRunner uses a completely different API.
The only scenario that could possibly work is this: a webapp which doesn't use any of the HTA-specific or XULRunner-specific API (i.e. behaves like a normal browser app). In such case, your app might work with HTA, XULRunner, as well as in any browser. Incidentally, this would take away any advantage of using HTA and introduce masive security holes because of the higher privileges; you'd be better off with using Google Chrome or Mozilla Prism for that.
(We've been trying to find a cross-browser solution for some time, and HTA is definitely not it)
I was tackling the related task of running hta's from various browsers. I've put my findings here for anybody else who is trying to do that and finds this question.
You can run hta's from several browsers, using the same mshta executable that IE uses. You need fully qualified URI's in your hta code, which isn't needed from IE.
Today (2011-02-01) I tried using hta's from Firefox (3.6.13), Opera 11 and Safari for Windows 5.0.3.
After some teething problems in Firefox I got hta's to work from those browsers. (In all cases these use the same mshta executable that IE uses. This is not hta's running in other browsers, but running hta's from other browsers. This might suit your purposes.)
The hta started desktop applications on my machine (as it does from IE).
The experience wasn't perfect. For IE I set root relative paths in the hta. For the other browsers you can't do that. You need to set fully qualified URI's for things like images, referenced hta's and icons.
So after a little editing I have the hta's working from 4 browsers (IE 8, FF 3, Opera 11 and Safari 5 (Windows)).
(Quick snapshot of that. I'm running hta's from a web server on the local machine. (I have no plans to run them from remote sites.) This allows my workflow to go from browser to desktop more smoothly. The hta's fire up local applications that do things like edit web pages (including the hta's themselves), validate those pages and fire up IDE's. Bridging the gap between browser and desktop apps. has been a liberating experience. I recommend it!)
Notes:
The Firefox development team have notes about enabling hta's which encouraged me to continue after initial failure.
To achieve this in Firefox configuration I set HTML applications to run under mshta.exe (called Microsoft HTML Application Host, in the combo box). Initially that didn't work. I selected "other" picked the same application by hand. That worked, though I have two identical looking entries! You need mshta.exe on your machine to run for any browser. I assume the normal way to install mshta is with IE. (mshta is essentially a modified version of IE, possibly not the current version!)
The Firefox developers have marked this as a strategic effort to dislodge IE from the Enterprise. Their implementation (and Opera's) force you to use fully qualified URI's but apart from that the hta's work as expected.
Firefox seems to cache old versions of the hta's, and doesn't download new ones, though it appears to download something! You might need to clear the cache during development.
My first attempt to do it with Chrome was not successful. Further investigation suggests Chrome doesn't have a native interface for invoking other processes, based on their file extension.
It isn't so much that IE hosts anything, but that mshta.exe hosts components it shares with IE. MSHTA is a script host, much as CScript and WScript are. While IE is also a script host (in the strictest sense) its primary purpose is to be a Web browser.
The Mozilla project mentioned previously is the closest alternative I have found that is based on a browser's innards.
Other script hosts exist for windows too. One of these is NS Basic/Desktop but it is based on standard Windows controls, not browser rendering and an HTML DOM.
Just to be clear: It is not IE nor MSHTMA that really renders a webpage. The rendering thing is partly build into the OS. Thus, things like Active Desktop (does anybody remember that XP thing?) or .HTA or .CHM work without IE. It's just the same way to recognise some HTML things.
I believe Internet Explorer's hosting of HTA apps works because their HTA host is registered to handle the extension. If this is indeed the case then in theroy another host could be used
For the sake of completeness I should note that I am not expeirienced in the development of HTA applications and am basing my response on my understanding of the Windows OS