With the Round-trip Editing Library for Domino WebDAV for IBM Domino on openntf which should enable me to open an attachment, such as Microsoft Word, edit, and save it back to the server.
I have configure my server with the necessary information but find it difficult to run the WebDocOpenSetup and the WebDocOpen.exe file on my 64bit window system, any idea how i could go about this?
I wrote this piece of code, so let me explain a few of the challenges you will face:
Windows will open anything that starts with http(s) using a webbrowser and not an app. It happily ignores file extension. Thus a different protocol was needed. I opted for webdav:// (like you have skype://, notes://, sap:// )
the helper application (on Windows - or the script for OS/X Linux) simply reacts on that protocol. The installer simply creates the needed registry entries. You could do that by hand
When you start any office application with an URL as parameter e.g. winword.exe https://.....doc the webDAV mechanism kicks in as desired.
The only thing WebDocOpenSetup does is to set some registry keys and register the WebDocOpen.exe as handler for the webdav(s):// protocol. The source code is included, you might need to recompile it for 64Bit
the helper checks the app needed based on the extension and launches it with the url (webdav replaced with http) as parameter
You can save yourself quite some trouble using https with a proper certificate. Self signed won't cut it
There is an article on my blog explaining more of the background
The registry entries are explained here
You might test with a Mac or Linux first to ensure all is working ;-)
Even without the little helper application you can connect using Explorer webfolders (not Internet Explorer, Explorer)
Good luck!
Related
I have installed webdav for Domino and made the required changes in the webdavconfig.nsf.
If I give designer rights to anonymous users, I can access and update the word documuments in the database through Internet Explorer and MS Word, but if I change them back to no rights, i cant. Of course I want to edit them with my own credentials.
What am I doing wrong?
OS windows 10
URL which works anonymous (????? are hidden)
webdavs://dev.?????.nl/webdav/domino/eod.docx
https://dev.?????.nl/development/webdab.nsf
https://dev.?????.nl/webdav/domino/
Any help would be appreciated!
I wrote that application.
You are in the tricky land of authentication. Domino supports: Basic, FormBased, Cookie based (LTPA) SPENEGO and SAML. The later 3 need configuration work.
What happens when you use WebDAV is that no longer your browser, but a local library (belonging to Explorer or Office) talks to Domino.
You can "manually" try that using File - Open and paste the URL to the document (the one with https://, not webdavs://).
The only thing that happens with a webdavs:// url: a little helper checks, based on extension in the registry, what app is needed (Word, Excel, OpenOffice) and then calls that app with the https:// url as parameter. Like starting e.g. Excel from the command line:
excel.exe https://someserver/path/spreadshit.xls
By default Windows now uses NTLM or Kerberos authentication, neither of them supported by Domino (There used to be a proxy translating NTML to LTPA by a 3rd party). So no credential reaches Domino. Hence you need anonymous access rights.
For older versions of Windows I described what you need to do to get Basic Auth going.
Never came around to check what setting you would need on Windows 8 or 10 to allow basic auth there. Also, in theory, SAML or SPENEGO SSO might do the trick.
If you got Mac or Linux, you could check them first.
So the challenge isn't with the webDAV plugin as such, but in finding a common authentication ground between the OS and Domino. Hope that clarifies it a little.
Let us know how it goes!
I looked into very many Google Chrome extensions and apps in order to find one that matches the following requirements:
runs in a Google Chrome tab
editor for any code, PHP, CSS, HTML
can load and save files (on my computer) and create new ones
works with local files on my computer
Is there any? kodingen, cloud9, shiftedit does not seem to make it on the localhost.
Maybe SourceKit will do?
SourceKit is an extension to your Google Chrome browser which runs in a separate tab. The files are stored in your Dropbox account, so not only can you access the files from your computer - you can access them from anywhere! It uses syntax highlighting like Notepad++ for a limited number of languages (you said php, css, and html - they are all supported). It can load, save, and edit text files locally on your computer if you install the Dropbox Desktop Application. This will also synchronize the files with your online account and thereby make them accessible from anywhere in the world.
That sounded more like a salesman's advertisement than intended.
Both Dropbox and SourceKit are free.
There are four catches as far as I can see:
Dropbox "only" offers 2GB for free, however, you can upgrade at any time if you're willing to pay.
Dropbox Desktop will only synchronize one folder (and all of its contents), but that's really not any different from a web site.
SourceKit will not debug your code, but will it highlight wrong syntax(only for certain languages).
EDIT Does not work offline.
I've tried it out, and it works well.
Sympathy Editor
Sympathy uses the npapi-file-io plugin mentioned in an answer above to allow you to edit local files.
Pros
Allows you to edit local files
Full syntax highlighting
Bookmark local files for easy access
Cons
Uses npapi plugin to read files, which means it has access to all your data
Unavailable on Chrome Webstore
Still under development
Only works on linux/windows as of the moment (not in mac)
If you are interested, you can see the README, or Manual on github.
Disclosure: I'm the primary developer of the extension.
Don't any of these extensions you have mentioned work with the file:/// protocol? They will work for the http:// protocol only if you are going to edit files inside your local webserver.
Instead of writing http://localhost/(...) you write file:///(...), where (...) is the full path.
In UNIX systems it is file:///home/jens/file.txt. In Windows it should be file:///C:\(...).
#Berk Demirkir may be right.
Here are the resources I found that may be of use;
32 Google Chrome Extensions For Smart Designers
Chrome Web Developer Tools No. 7 on the above list
There's no extension for editing local files.
But you can write one!
Acesses to local filesystem cannot be done using Chrome's Extension API.
But you can use HTML5's File API (which is draft) or Local Storage. If none of these storage methods sufficient for you, you can build a NPAPI Plugin. Chrome supports NPAPI Plugins. There's also a project called npapi-file-io in Google Code which aims to access local files from Google Chrome Extension context.
Edit:
Now, there's one usable editor, Symphaty. You can use Capt.Nemo's Symphaty editor.
Edit 2:
NPAPI plugins are phased out from Chrome since version 42. The only alternative would be to use a wrapper native app and communicate using Native Messaging API.
ShiftEdit can be used to work locally, you will need to have XAMPP or equivalent installed.
hi
i have a problem at my production site, client reported that he is not seeing data in lists of sharepoint, as well drop downs which have years in pages of site appear empty with one user A on machin X having with windows 7. but data and comes up and drop downs are now populated when accessed from machine Y with same user A.
i dont knw wht really the problem is. As to development site this issue is not produced,
plz help,
thnks in advance
From your question, I gather the data does exist and the same user can see the information from one computer but not another.
A couple things spring to mind. (I am presuming usage of Internet Explorer since SharePoint 2007 has some rather weird rendering issues with other browsers. Correct me if this is an incorrect assumption.)
First, Windows 7 has later versions of IE which can refuse to send network credentials to a server it doesn't think is part of the intranet (corporate network). What makes this especially frustrating is that IE will prompt for network credentials (a result of the challenge from the website) but will not transmit those credentials. Examine the IIS logs to see if this is the case. The requests will be void of credentials using IE but will be present using Firefox (and presumably any other web browser). The fix for this is usually as simple as adding the domain into the Local Intranet zone in Internet Options.
If this is not the case, can you confirm the user is using the same credentials? Is this integrated authentication using Active Directory or forms authentication?
Are there any differences between the two computers with regards to how they reach the SharePoint site? (Such as one is VPN, the other is directly connected)? Or are they essentially equal but with different browser/OS configurations?
Are the lists standard out-of-the-box lists or have they been customized with SharePoint Designer or any other means? Are you injecting JavaScript via a Content Editor Web Part which might not be executing correctly?
It would be very helpful to know browser versions used, OS versions used, differences in connectivity to the resource from each machine, type of authentication used, and any other thing you can think to list.
I wish you luck in tracking this down!
Windows 7 or xp has nothing to do over here probably it has to do with the browser which he is using to browse the site ask him to chk the internet explorer settings and verify that he has enabled execution of javascript and other related things
I am thinking about having the following use-case:
User installs application on local machine.
User goes to our website, and are presented with many links (choices).
User clicks on a link.
Application starts, with some information contained within the link passed to the application.
Step 4 is obviously a security minefield. The end goal is that the user makes a choice, and if the application is installed, it starts with some information passed to it (ie command line parameters, or perhaps a temp file somewhere on the user's machine)
Can I/ Should I access the registry from javascript? Are there any ideas about how I might go about this? Do you have an alternative suggestion?
Assuming the applications the user installs are also developed by you.
Register a file extension for use by the specific application - then your web links can be links to a file that is downloaded and auto-run by your app. The file could contain details on the defaults for your app to use.
Sort of like how clicking on a .pdf file opens your pdf reader.
As an alternative to the file-extension solution you may want to know about Custom Application Protocol feature. Link is for Windows but there are nearly same techniques on other systems. I can't say if this approach works in every browser but you may want to try it out.
Accessing the registry from JavaScript inside a browser is nigh on impossible for the security implications. To access the registry from the web, I'd imagine you'd have to use a binary (C++ or others) program that can read the registry, but also has an HTTP module to communicate with your server.
Sounds like you might need the Click Once deployement feature for your app. I think once it's installed over http there should be a pretty easy way to launch an executable.
http://en.wikipedia.org/wiki/ClickOnce
We're using the Mantis bugtracker (version 1.1.8), which is based on PHP. To ease the workflow of adding bugs we'd like to add an option to paste screenshots from the clipboard directly into the 'new bug form'.
Screenshots make bugreports much more valuable for developers, so I'd like to make adding them as easy as possible. Preferably without using an external application, but right in the browser.
I've looked all over for a way to add this, but no luck. How do other people do this? Am I missing something obvious?
edit: The bugtracker is a private one, in a small company, so I'd be willing to accept the security risks that for example Java applets present.
There isn't really a way to do this short of using ActiveX, applet or Flash-type technology on the client. Even then, there are numerous security roadblocks. A browser has no easy way to convert stuff from the clipboard into a suitable format for upload to a website, and even if it did there would be security concerns. For example, malicious code in a page could copy sensitive information from your clipboard and send it to the page's site without you even knowing it was happening.
Update: There is a standalone screen capture utility which claims to work with Mantis (and a whole bunch of other bug-trackers). This is probably your best option.
There is a drag n drop image attacher Java applet for Atlassian Confluence which has the functionality you need. It only supports Confluence but as the sourcecode is freely available under BSD you should be able to customize it to your needs.
Forgot the link:
http://confluence.atlassian.com/display/CONFEXT/Drag+and+Drop+Image+Attacher+Plugin
I've managed to build my own solution that works quite well. It places a Java file upload applet on the pages where you'd want to attach a screenshot. The applet has two buttons:
'paste screenshot', which pastes an image from the clipboard into the applet
'upload screenshot', which uploads the pasted image to the /tmp dir on the Mantis server and uses a javascript callback to place the autogenerated filename of the uploaded image into a form field.
Once the form is submitted, a new function in Mantis uses the filename in the form field to move the image from /tmp to the final location and processes the image just like other attachments. If the form is never submitted the uploaded file remains in /tmp and will eventually be purged by the server.
It works well, but has one drawback that I cannot avoid: I'm using Java to get access to the client's clipboard, but that requires breaking the JVM sandbox. Apparently, this can be done if you digitally sign the applet, which requires a rather expensive yearly payment (something like $500) to a company like Verisign (currently free options like cacert.org are still limited in their usefulness).
Another way to allow Java applets access to the clipboard is to create a file called .java.policy in your home or profile directory. This file should contain the following (Replace the domain with the domain that hosts your Java applet):
grant codeBase "http://bugs.example.com/-" {
permission java.awt.AWTPermission "accessClipboard";
};
Thankfully the solution is cross-browser compatible since the JVM always checks the same file regardless of the browser used. Since my solution requires having this .java.policy file on each client computer I don't consider it ideal, but workable in a controlled company environment.
I looked in to this also. No real easy way, so instead I allowed them to upload an unlimited number of files and those files would then be "attached" to that bug. It actually turned out to be better because they can upload screenshot, spreadsheets, word docs, etc.
Like yours, this is an internal only site so security is light. I did this in ASP.Net, but the general idea is that when they are looking at a page for a bug they have an upload box. When they upload something I pre-append it with the bug id. So ScreenShot.jpg becomes 233_ScreenShot.jpg.
Also on that page is a grid (GridView) that is bound to all of the filenames in my upload directory that start with that bug id.
To see what this looks like click here.
For tech-oriented users, there's always to possibility of using Eclipse + Mylyn + Mylyn-Mantis connector.
Then uploading screeshots is very easy:
Screenshot upload http://img216.imageshack.us/img216/246/screenshotattachments1.png