I want to open an agent via an URL and provide some additional parameters (re-writing an old Domino app, I want to maintain some document handling that resides now in web enabled agents)
I am trying:
...
var unid:String=mybean.myObject().getUnid();
importPackage(java.net);
importPackage(java.io);
var agent:URL = new URL("myagent?OpenAgent&unid=" + unid);
var agentConnection:URLConnection = agent.openConnection();
...
this causes an error. if I look in the log the address I am directing to has become: "dir/db.nsf/myagent?OpenAgent&unid=7FC612D6736836ECC125822800622FF1"
any easy way to get this old agent running?
You might want to revisit your approach. Instead of using http(s) to access your agent, you could call it directly with agent.run. It would require some adjustment on the agent side (still can be used dual use) and saves you the TLS headache. Follow this blog entry for inspiration: https://wissel.net/blog/2012/04/reuse-web-agents-that-use-print-bean-edition.html
Does your server or database use only https? I think that requires different code and there are issues with Java 1.6 and TLS versions.
Related
I am developping web applications using the Xpages framework from the IBM Lotus Notes technology.
My users don't use the embedded Notes Client browser, but use a regular modern browser (Firefox, Chrome) to browse Notes applications.
Everything is ok when the user has an internet connexion, he can access the application on the online server through his favorite browser.
However some of my applications need to be used Offline, in local. When a user works in local, he opens the IBM Notes Client, go to his workspace and click to open an application locally. Then, the Notes Client runs a http server on a random port and open the application with the embedded Notes Client browser.
What I want to achieve is to be able to open the application on a regular browser (Firefox, Chrome), by just using the default system browser and not the embedded Notes Client browser.
Here is what I tried without success :
With window.location.href I get the port where the local http server runs and the path to the page that is opened in the embedded Notes Client browser. I get this kind of result :
127.0.0.1:54428/xsp/Gfn/CoffeShop.nsf/xp_home.xsp?OpenXPage&&xspRunningContext=Notes
So I just keep the interesting part :
127.0.0.1:54428/xsp/Gfn/CoffeShop.nsf/xp_home.xsp
Now I need to pass the session id has a parameter of this http request so the browser will have the right to access the application. I get the session ID with the following :
facesContext.getExternalContext().getRequest().getSession().getId()
From this I get an ID and I build my complete http request :
127.0.0.1:54428/xsp/Gfn/CoffeShop.nsf/xp_home.xsp?SessionID=ID-fae7aca8f062023972fe35e5909b0106f44ba2ae
But when I try this into a regular browser, instead of getting the page I get an error 500. If I look at the log of the server, I see the following error message :
Exception Thrown
javax.servlet.ServletException: The request is not coming from a trusted Rich Client part
But I am sure my ID is correct. I tried to investigate this on the internet but no success for now, I would be happy if someone has an idea about what do I miss? Or maybe another way to open a local application in the default system browser?
Thank you!
In short, you can't. This is disabled by security restrictions.
But maybe you should think again about a XPiNC application: With 9.0.1, the underlying XULRunner component was upgraded and supports now HTML5 and a lot of the "newer" features.
It matches Firefox 10.0.6, here are the HTML5 test results:
https://html5test.com/s/555ae51ca555ac7b.html
The only reasonable action you have at you disposal is to install Domino designer on the clients. Then you get the nhttp task that serves to a standard browser (you might get away analysing what nhttp needs and only install that part).
The caveat there: the local nhttp does not support authentication. So you need to hack around it (e.g. copy data back and forth between the local NSF and the properly secured one).
Alternative you could try the approach I took with vert.x (should work with any Java container, but then you won't have any XPages, just raw Domino data.
Danielle pushed that forward with the Crossworlds Project - which might be what you need.
Stephan says it as it is: the way you are considering is just going to cause you huge headaches.
If offline capacity is a must, have you thought about creating a pure Notes-Client application? That would certainly be far easier.
temp:=#DbLookup("Notes":"NoCache";"ARRoW/SSS":"sss/sssProj.nsf";"(Lookup for Community)";"State of Maine";2);
temp1:=#DbLookup("Notes":"NoCache";"ARRoW/SSS":"sss/sssProj.nsf";"(Lookup for Community)";"State of Maine";3);
temp2:=#DbLookup("Notes":"NoCache";"ARRoW/SSS":"sss/sssProj.nsf";"(Lookup for Community POC)";"State of Maine";4);
#If(#IsError(temp)|#IsError(temp1)|#IsError(temp2);"Error";temp + " " + temp1 + " " + temp2)
Hi this works on Lotus Notes Client but doesn't work on web Any help is welcome thanks in advance!
There are typically three types of root causes for something like this.
One type of problem is server trust. This only applies if there are two servers involved. I.e., the web server is ServerX/SSS and the code is trying to access ARRoW/SSS. You need to review ARRoW/SSS's server document and check whether "ServerX/SSS" is listed in the field for "Trusted servers". (Also note that if this is a really, really old version of Domino - before version 6 if I recall correctly - then the trusted servers feature is not there and you cannot make cross-server calls to #DbLookup in web code.)
The second type of problem is that the server where the code is running can not resolve the name of the server where the database lives. The code is accessing server ARRoW/SSS, but you haven't said whether ARRoW/SSS is the actual web server, so let's look at both cases.
Assuming that it is all happening on one server, there can still be a name resolution problem because of the way the formula is coded. Try specifying "":"sss/sssProj.nsf" instead of "ARRoW/SSS":"sss/sssProj.nsf". If that fixes your problem, great! But it means that you still have a problem either in your server document or with the DNS configuration on your Domino server and you should address that. You should probably continue with the troubleshooting that I give in the next paragraph. Just bear in mind that everything I say there is true even if ServerX/SSS is really the same as Arrow/SSS.
If the code is running on web server ServerX/SSS, then you need to make sure that ServerX can connect to ARRoW/SSS. The easiest way to do this is to bring up the console for ServerX and enter the command 'trace ARRoW/SSS'. If it fails, check the server documents and/or connection documents for correct IP addresses or host names, and open a command window on the server and try a ping using the exact information in the server documents. If it fails, you have a networking issue. One of the underlying causes I've seen for a problem like this is that there is no connection document (because the servers are in the same named network, but neither the IP address nor the fully-qualified host name is entered in the networks table in the server document, so Domino just asks DNS to resolve the common name 'ARRow' - but the DNS configuration on the web server does not include a default search path so the name is not resolved. But you need to check everything until you can get a 'trace' command to succeed.
The third type of problem is Access Control. This is a broad category that comes down to the fact that the identity that the code is running under either does not have access to the server ARRoW/SSS, the database sss/sssProj.nsf, the view (Lookup for Community)" or the document(s) with the key "State of Maine". There are a lot of things to check. If the code is running in a field formula, the identity is that of the user, and if the same user does not get the error through the web client then you need to look at the database properties for sss/sssProj.nsf and check the maximum web access level. If the code is running as an agent, you need to check the agent properties to determine what identity the agent is running under, and then review everything: the security settings in the server document, the database ACL, restrictions on the view, and reader names fields in the documents.
Is there any method to tell from javascript if the browser has "enhanced security configuration" enabled?
I keep running into problems with certain controls not working from within dynamically loaded content. This only happens with browsers running on Windows Server 2003/2008 systems - even when I add the server to the "trusted" zone.
Maybe somebody has already develoepd a method for accomplishing this task?
Thanks in advance
Instead of testing for IE ESC directly, we can test for its effects.
I found that with ESC enabled the onclick events of dynamically added content would not fire.
So I am testing those events directly.
var IEESCEnabled = true;
var testButton = $("<button style=\"display: none;\" onclick=\"IEESCEnabled = false; alert('No problems here.');\">Test IE ESC</button>");
testButton.click();
if (IEESCEnabled) {
alert("We have a problem.");
}
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
In my application a test like this forwards the user to a page explaining their issue. It is accompanied by a noscript element to check that they have JavaScript running at all.
I don't think it's possible, and if it still is, than that's a bug that might sooner or later be fixed.
One of the main points of this "extra security" was for the client to have it but not to be detected by the servers, thus leaving them no way to know when to try to circumvent it and when not.
Isn't javascript disabled when using enhanced security configuration?
Then if you only want to display a message to the user, simply display a message in normal html and hide it with javascript so only users without javascript will see it. If you need to handle it on the server side (e.g. outputting a differerent version of your website) simply include javascript to redirect users to your javascript enabled version. Users without javascript will remain on the non-js page.
If only scriptable activex are disabled, the same method applies, simply insert a activeX and try to "script" it, if it fails you can redirect, show a message etc.
The above of course doesn't detect enhanced security configuration per se, but the symptons that occur when it is enabled. So it probably wouldn't be able to distinguish between users with using enhanced security configuration and users that simply have JS/ActiveX disabled or use a Browser that doesn't support scripting in the first place.
I think you can look for SV1 in the user agent string.
I need to implement a browser plugin which can register its own protocol (like someprotocol://someurl) and be able to handle calls to this protocol (like user clicking on 'someprotocol' link calls function inside my plugin). As far as I understand, Skype does something similar, except I need to handle links within page context and not in a separate app. Any advice on how this can be done? Can this be done without installing my own plugin, with the help of flash/java?
Things are going to be slightly more complicated than you think.
You're going to have to create an entire application, not just a browser plugin (that plugin can be part of your application). The reason I consider it to be a complete application is that you're going to need to modify registry settings on the client machine to register your custom URL handler.
Here's an MSDN article describing exactly what you have to do to register the custom URL handler on a Windows client:
Registering an Application to a URL Protocol
I'm thinking about exploring the idea of having our client software run as a service on a high port and listen for simple http GET requests from 127.0.0.1. The theory is that I would be able to access this service via js from a web page that is served from my site.
1) User installs client software that installs itself as a service and waits for authenticated requests on 127.0.0.1:8080
2) When the user hits my home page js on the page makes an xhtml request to 127.0.0.1:8080 and asks for the status
3) The home page then makes another js request back to my web server sending the status that it received.
This would allow my users to upload/download and edit files on a USB attached device in real-time from a browser. Polling could be the fallback method which is close to what we do today.
Has anyone done this and what potential pitfalls are there? Will this even work?
I can't see any potential pitfalls. I do have a couple of points however.
1/ You probably want to make sure your service only accepts incoming connection from the local machine (127.0.0.1). Otherwise, anyone could look at your JavaScript and figure out that it's talking to [your-ip]:8080. They could then try that themselves from a remote site (security hole).
2/ I wouldn't use port 8080 as it's commonly used for other things (alternate HTTP servers, etc.). Make it configurable and choose a nice high random-type value.
3/ I'm not sure what you're trying to do with point 3 but I think you're trying to send the status back to the user. In which case, why wouldn't the JavaScript on your home page just get the status in a single session and output/update the HTML to be presented to the user? Your "another js request back to my web server" doesn't make sense to me.
You may not be able to do a xml http request to 127.0.0.1 as XMLHTTPRequest is usually limited to the same domain as the main content is being served from. I'm not sure if this restriction applies if the server is on the client's machine. That being said, you could still create a <script> tag that had the src pointing to 127.0.0.1, and have the web server return some Javascript to run. If you only need a simple response, this could work well.
I think it is much better for you to avoid implementation of application logic in JavaScript and html. Once user clicks button on a web page JavaScript should send request to your service and allow it do the rest of the work.
You could have problems with step 1 (Client installs itself) depending on your target user base.
You will need a customised install for each supported environment (Win2K, Vista, Linux, MAC OS 9.0/10.0 etc.).
If your user is on a locked down at work PC this simply wont be allowed.
To some users this might look distressingly similar to a trojan unless you explicitly point out you will be installing software that runs as a service.
You didnt mention an unistall procedure. Users resent "Adobe" like software which installs itself and provides no sensible un-install options
Ohterwise the approach is sound, and, there are are couple of commercial products out there that use exactly this approach!