I would like to put a path to a file on an XWiki page.
For a Windows file share this works:
[[For Windows>>unc://filehare/directory$/index.html]]
For linux:
When I enter file:///mnt/directory/index.html in Firefox, the index.html page is displayed.
But when I use any of these syntaxes in XWiki, nothing happens.
[[For Linux>>file:///mnt/directory/index.html]]
[[For Linux>>file:mnt/directory/index.html]]
[[For Linux>>file:/mnt/directory/index.html]]
[[For Linux>>unc:mnt/directory/index.html]]
[[For Linux>>unc:/mnt/directory/index.html]]
[[For Linux>>unc:///mnt/directory/index.html]]
Can anyone tell me what the correct syntax is?
First of all, you need to clearly understand the fact that the UNC protocol (and links using it) is used to address/reference files on other computers in your local network only. They can also be links to your own computer (using your computer's "name", but most of the time they refer to other computers). Some more details about UNC: https://whatis.techtarget.com/definition/Universal-Naming-Convention-UNC
Second: It is not clear what you mean by "on Windows" vs "on Linux". Is the XWiki server running on Windows in the first case and, in the second case it is a different XWiki server that is running on Linux? What I actually think you mean is that you tried to access the same XWiki server from 2 different computers: first you were using a computer with Windows operating system (possibly on Internet Explorer/Edge) and in the second case you switched to a different computer that was running a Linux distribution with the Firefox browser. I will assume you are in this latter situation, as it is the one that makes most sense. Please note that UNC links will only work for people that are using a Windows computer when viewing the XWiki page.
Third: Your first example unc://filehare/directory$/index.html is a reference to a file on the fileshare computer (which is somewhere on the Network, other than the current computer you are using right now to test, referenced with the UNC protocol mentioned in my first point). However, your second example file:///mnt/directory/index.html, which is not working, is a reference to a file that is on your local computer, the one you are testing with ("mnt" is a folder on your computer). In this second example, your particular usecase is no longer allowed since a good couple of years ago by modern web browsers (including Firefox, the browser you are testing with) because of security problems. Internet Explorer (being an old browser), might still work by default, but you should not really be using it in 2018 anymore. Feel free to read more about this subject on http://kb.mozillazine.org/Links_to_local_pages_don%27t_work
In XWiki, any of the following links are equivalent:
[[UNC file on the "server" computer>>unc:\\server\folder\file.ext]]
[[UNC file on the "server" computer>>url:file://///server/folder/file.ext]]
[[UNC file on the "server" computer>>file://///server/folder/file.ext]]
...however, is not really something related to XWiki, but to the capacity of your current browser to interpreting those links. By default, as said, this is no longer supported or simply disabled. Some browsers might still support disabling this protection, either by some advanced setting or by installing a browser add-on:
Chrome: https://chrome.google.com/webstore/detail/enable-local-file-links/nikfmfgobenbhmocjaaboihbeocackld?hl=en
Firefox: https://addons.mozilla.org/en-US/firefox/addon/noscript/
...but you would have to do this change and install this type of add-ons on all the computers that you wish to use when reading that page, which is not very practical.
Related
After thinking about this for 2 weeks, I have to ask this question.
I've created a NW.js app that works smoothly and nice on 7 different laptops and PCs. The app shows html videos and contains a bunch of javascripts, I've got deloped since 2 years. Alls this works fine on every laptop/PC.
Here comes the problem:
On one laptop the app works, too, but the app isn't able neither to show HTML frame contents nor to execute js scripts from a specific web domain. This only occurs with a specific domain (that I'm the owner of).
The strange thing is, that this happens only on one laptop.
The laptop uses the same internet connection as some other devices. I reinstalled the app, deleted all subfolders from the app folder, but the error is back. In the frame I see the silly message, that the website is down or moved.
You likely have a system-wide proxy configured or possibly some AV software installed on that laptop is blocking that site. Attempt to access the same URL through another browser (Chrome, Edge, Firefox, etc.) to confirm.
Could be related to your hosts file.
C:\Windows\System32\drivers\etc\hosts
That is a plain text file without an extension. You can put URL's or IP addresses in it and it will block any access to them globally on the computer.
Though Sysrage is probably right, it's more likely that you just have some AV/firewall/security software blocking stuff it shouldn't (happens all the time, they can be "over protective" sometimes)
If it is something related to your NW.js install, and it isn't happening on other machines (so you know your app code is correct), then you could try deleting the app data folder for you app. To find it's location on the computer run console.log(nw.App.dataPath). It should be something like:
C:\Users\YOUR USER NAME\AppData\Local\YOUR APP NAME
You can just delete the whole folder (make sure your app isn't running first). Then the next time you open your app it will recreate that folder (it's a chromium thing). Things like saved passwords or dev tool customization or spellcheck dictionary modifications are stored in there. So maybe there's just something funky that needs cleared out.
When I try to browse to netflix.com (for example) in IE11 (on Windows 10), IE11 shows a page with the title "We recommend viewing this website in Microsoft Edge", and the site automatically gets opened in Edge.
Does anyone know how that works? Is it done via an internally compiled list of sites or something I can set up on my website?
Thanks
You had asked, "Does anyone know how that works? Is it done via an internally compiled list of sites or something I can set up on my website?"
When a user goes to a site that is incompatible with Internet Explorer, they will be automatically redirected to Microsoft Edge. For more detailed information, you can refer to the Redirection from Internet Explorer to Microsoft Edge for compatibility with modern web sites.
Microsoft maintains a list of all sites that are known to be incompatible with Internet Explorer. You can view the site list here. If you want to add your site to the incompatible site list then you can refer to the Request an update to the IE compatibility list.
The MS Edge 87 or greater browser installs the BHO named IEToEdgeBHO that performs the redirection based on IE compatibility list from IE to Edge browser.
You can find this BHO at the location below on your machine.
C:\Program Files (x86)\Microsoft\Edge\Application\<Your_browser_version>\BHO
If you want to achieve something similar using the code in your own site then you can refer to the example on this answer. The test shows results for the Edge legacy browser but it can also work with the Edge (Chromium) browser.
Note: that the example code mentioned in the answer may break when the Edge browser is not installed on the machine. so you can try to modify the example to handle that kind of situation.
Helpful reference:
What “magic” causes “cnn.com” when typed in IE11 to automatically launch Edge (Chromium)?
Netflix specifically is on a list of websites that automatically open in Edge when they are accessed from Internet Explorer. The list is maintained by Microsoft.
If you do not want to go through the application process to get your website added to this list, you can resort to detecting which browser the user is on and handling the notice yourself.
Here is a decent list of current Internet Explorer user agents.
I have found a strange issue which I do not completely understand. When I run the LoadRunner with just a single protocol, the browser (when recording starts) is ran but says "page not found" (as if the proxy was not set).
How come? The protocols specify what traffic will be captured but I assumed in just does not record the ones not specified. But why the browser could not find the page in single protocol and could in multiple?
I've found that the single protocol mode (I assume web here) is somewhat erratic and does not work all the time. The workaround is to use the multiple protocol mode, but select only Web (HTTP/HTML). This works much better.
The actual reasons for why this is the case are unknown, but at least give it a try!
As for other issues:
Check that your PROXY settings are correct when you invoke IE for recording. Your issue sounds a little like a proxy issue, but please post more details if none of the above works.
Over 90% of recording issues can be tracked to environment items, specifically do you have the right match up between version of LR and version/manufacturer of your browser plus are you signed in with the proper credentials plus do you have any conflicting software packages loaded, such as antivirus, which could be impacting the recordingf mechansim.
Where to start?
Makes sure you are signed in with Administrative credentials
Disable any antivirus running locally
Validate your browser manufacturer and version with the requirements for your version of LoadRunner
I installed Microsoft SharePoint and Project PWA on Windows Server 2008 R2.
When I want to open Library in Windows Explorer, I randomly get an error:
Your client does not support opening this list with Windows Explorer
When I open IE it's working for 1st and 2nd time, but after some clicks it's not working anymore and I need to restart IE and then it normally works for couple of times.
When it not working through Sharepoint it also not works via \server\DavWWWRoot\PWA and oposite.
I'm searching through the web for weeks and didn't find any solution.
Do you have any idea what should be wrong here. Any suggestion is welcome :)
I had the same exact issue with Windows 7 and explorer view. The following steps resolved the issue for me:
First - be sure that the Web Client service is running (run>services.msc).
Next - In I.E. check Tools>Internet Options>Security>Local Intranet>Sites>Advanced and add the site that you want to use explorer view with.
This finally fixed it for me. I hope that you have already found a solution to this issue! I was surprised at how difficult it was to find a solution to this problem!
This error message is a symptom to a billion different problems.
I solved this problem when I realized my XP32 box could do this just fine with IE8. So I reverted to IE8 in 7x64 (you have to do it by uninstalling updates for IE until you're back at 8) and it didn't work. The build versions were different and on the 7x64 "about" box it said IE8 was using 256-bit cipher while in XP32 it had 128-bit. That to me was a hint that there may be 64-bit issues even when you run the 32-bit executable.
Then I found this hotfix so I reinstalled the windows update for IE10 and then installed this hotfix. Now I'm able to open the TeamCenter site in question in windows Explorer. IE10 reports it's version 10.0.9200.16686. I cannot guarantee that it was the hotfix alone (and not also the reinstallation of IE10) which fixed it. But I'm willing to bet it was the hotfix alone.
In XP I found it impossible to then map this network location to a drive letter, as mapping doesn't like URL's. However in Windows 7 you can transform the URL so that it is interpreted as a Windows share. If the URL of a given folder is of this form:
https://somesharepoint.com/folder1/folder2/folder3
you can also access it as
\\somesharepoint.com#SSL\DavWWWRoot\folder1\folder2\folder3
and, in this form, it can be mapped to a drive letter.
I do have issues at that point that even with IE10 open and logged in to the site I see some random time-out like problems and I get kicked off (and prompted to log in again in IE10). My situation is complicated because the site I'm accessing requires an Exostar token to log in, so I have to log in via website no matter what.
If it helps any one do the steps suggested above:
Make sure to use 32 bit internet explorer (program files (x86)/internet explorer).
Like was mentioned above Web client must be started.
You may also need to add your site to trusted sites in internet explorer.
Make sure enabled protected mode in internet options is disabled.
This is what finally fixed it for me: Check "Keep me signed in" on the login page. This was the key for me. Will not work without it checked in my case.
I had the same symptoms, and it turned out I don't have a root site collection. Creating one solved this for me.
Summarized the troubleshooting steps here:
http://letitknow.wordpress.com/2012/07/22/your-client-does-not-support-opening-this-list-with-windows-explorer-error/
There can be multiple reasons for it.
One could be using IE x64 version. It won't work there.
Secondly, check out this blog:
http://blogs.technet.com/b/asiasupp/archive/2011/06/13/error-message-quot-your-client-does-not-support-opening-this-list-with-windows-explorer-quot-when-you-try-to-quot-open-with-explorer-quot-on-a-sharepoint-document-library-in-office-365-site.aspx
I experienced the same problem as well.
And I found out that if none of the above options are working, and if you work in an organisation, maybe the proxy is blocking the "Open with Explorer" option.
I did the same, and removed the proxy and it worked just fine.
this fixed it for me ( however in windows server 2008 you may need to install desktop experience i think its called)
After you log into windows go into services then restart the WebClient then see if you can use explorer view without the error " your client does not support. blah blah blah" if it does work then. make a batch file that says:
net stop webclient
net start webclient
then make a scheduled tasks that runs that batch file at start up. Have it run as a user with administrative rights, make sure you tell it to run even if user is not logged in. it should prompt you for the password of the admin account you selected. this worked for me with windows 7.
I found online where the error can occur intermittently with SharePoint 2010, however I think the SharePoint version is irrelevant. They said the client polls for a SharePoint root site and that the error occurs if one isn't found.
We have not seen the error since I created a root site even though we’re only using WSS3. Our errors began when we changed clients to Windows 7. So in our case it sounds like the issue could be the root site polling due to an IE8 security change in Windows 7.
SOLUTION:
*you on x64 bit machine* so solution is that there is no problem but you are using the wrong IE shortcut.
There are different IE types you can use (just type Internet Explorer in start search bar) and you will see..
Internet Explorer (64-bit) - won't show any sharepoint add-ons
Internet Explorer (No Add-ons) - won't show any sharepoint add-ons
Internet Explorer - only this will show sharepoint add-ons and will
work so basically make sure you always use this version of IE
I have developed a webapplication in my local machine. the application is hosted on tomcat 7.0.22 server. the application is accessed using http://localhost:8080/app
When i use this in my localmachine, I am not facing any problems. But when I intend to share the link with my fellow team mates using the links http://myipaddress:8080/app, I am getting Javascript errors. I placed the js files in the build path of the application.
Even i have noticed the tables width are changed in the same browser
I am unable to find the problem. Can any one help
Thanks,
Vamsi
When testing on your own machine, use your own IP instead of "localhost" and should be able to compare apples with apples and avoid confusing cause and effect.
I would say to check the configuration of your host or vhost files, but if all included JS files are on the same host, that is unlikely to be the problem.
My guess is that you hard coded a path somewhere or that the problem is related to some other difference between testing from your machine and their machine (different browser, versions, plugins, etc) and not actually related at all to the domain. Could possibly also be a file permission problem (but that is a wild guess).