I am trying to programmatically generate lotusscript (in a form of a scriptable button) from a web application (Java EE) and send it to an end-user who will then run it in his/her Lotus Notes client.
How can I achieve this? Is there an API for me to use in order to embed lotusscript in an email?
Rather than trying to embed a button, I would consider taking advantage of the 'stored form in document' feature of Notes.
I.e., using Domino Designer I would manually create a database (I'll call it "MyDb.nsf" for convenience). Create a form in this database ("MyForm" for convenience) and set it up with the required fields for an email message (SendTo, Subject, Body, etc.). Then create a button on the form and enter the LotusScript code.
With this done in advance, your code can take advantage of the optional attachForm parameter in the Document.send() method.
What you would do is open MyDb.nsf in the usual way, then use Database.createDocument() to create your document in that database, then use Document.ReplaceItemValue("Form","MyForm") to bind this document to your form. Also set the other Items (e.g., Subject, SendTo, Body) as needed, and when you're all done call Document.send(true). This will embed your form in the document and send it, so the LotusScript code will travel in the embedded form that is sent with the message.
I think this might be the best method for you, because I think that this will preserve the signature on the form when it embeds it. I'm not sure about that, but on the other hand I'm much more certain that any other way of sending with CORBA/IIOP will give you an unsigned script (because CORBA/IIOP has no access to the private key needed to sign the document). And an unsigned script will mean that your users get ECL warnings when they execute it -- and that could result in them adding an entry to their ECL to permit unsigned scripts, and that's a bad security practice.
Here is an idea. I haven't tried it and am not certain that it will work:
Create form with a LotusScript button in Domino Designer and set to be stored in the document
Create a document with that form
Export the document as DXL (Domino XML)
In your Java EE application use ncso.jar to import the DXL (you can modify the LotusScript in the XML first as needed)
Email the document using Document.send(). When connected to Domino server with CORBA/IIOP, I think this should work.
Update
You might be able to skip the DXL part and just modify the LotusScript in the document item. I understood that you have to modify the LotusScript for each recipient. If not then everything is much easier (see Richards answer).
Another option is to embed a URL to open a Page design element with your code (or a call to the agent) in the QueryOpen, so it runs when the page opens.
Notes://myserver.mycompany.com/utilities.nsf/MyTaskLauncher?OpenPage
I'm not sure if it could pass parameter values or if you have to rely on the user's credentials to determine the proper information.
Advantages:
Code resides in one location, so I can update it if I find out there
was a bug in the original version.
Minimal manipulation of the user's mail file with stored forms.
Smaller email message, since I don't have to send along form
information.
Easier to build a simple string in Java EE than the higher-powered
solutions.
The agent can either use the signing ID or run with the user's
credentials.
Can be sent to any email address, so long as the recipient has a Notes client.
Related
I retrieving the Off time of a page and returning offtimeQuery.toString() and retrieving the page title String resultPageTitle = resultPage.getTitle(); using java.
I am sending an email to the content authors of all the pages which have reached off time. How do i display this off time and page name in my HTML email using javascript?
It is near impossible to make an email with JS in it. If you do manage, then half of the email clients will tear it apart to protect to client-side computer.
Instead, I assume that you are using a Linux box for hosting, you could do two things that would work. Use a bash file or equivalent to dynamically create the page and then fire it off at given times, followed immediately by an email that serves the HTML of that page. That is pretty easy.
The other way would be to use a JS file to do the same. This could work through either time-based(HARD) or by you accessing the page through a browser when you wanted it to go. Again, dynamically create the page with JS and then use the system to send the HTML of the page.
Don't use javascript. Almost all HTML email clients will not run any Javascript, because it is a huge security hole.
Instead put the relevant data into the body of the email as you construct it in your Java code. Presumably you have, in your Java code, those bits of data, and you have the HTML content you're sending as an email. Insert the data there, at most basic using String.format(template, data, ...). But if you are going to do anything other than trivial replacement, use a proper HTML templating system.
Don't try to include any javascript with a HTML email. You may be able to find an email client where it works, but won't for most of your clients.
Javascript gets stripped from email messages due to concerns with security. You could force a redirect and perform phishing attacks, and steal other nasty info such as cookies from the domain that the email was sent to if Dynamic emails were made possible with javascript.
If you are really interested in displaying dynamic content, and don't care how, think about creating a server script which returns an image. You could pass a static identifier to the script, and it could return a dynamic result.
See my project in php at https://github.com/TabLand/EmailTracker which generates dynamic images. Only the time string is dynamic. I'd show you the demonstration, but would end up logging your useragent and IP address!
I have an existing swing desktop application that I wish to convert to a web application. The first thing that is stopping from doing so is that the desktop application deals with writing and reading from PDF files. Also the user fills up the PDF forms which needs to be read by the application.
Now a typical use case in the desktop application is like, the user logs in opens a PDF form and fills it up. The swing application manages where the file is stored so it goes to the file and reads the form, extracts the data and stores the data in the db. The user might not fill up the form all in one go. He might save it come back to it later and continue.
All of this needs to be done by the web app now. My problem is I don't want the user to download and upload the form multiple times to the server. That would eat the bandwidth and also asking the use to save the file locally and upload it back once he completes filling the form doesn't appeal to me since the desktop application nicely used to manage the location of these files as well.
Would I need to implement something like a dropbox kind of thing? A small deamon running continuously to check what file has been updated and upload it to the server? That would be difficult since at the server I wouldn't know if the file was latest or not. Is there anything like this that someone might have done before?
I have anther suggestion: why don't you show the user a form with the same fields and transfer them to the PDF after the user submits. This way the Pdf does not leave the server and you transmit just the minimal amount of data.
Switching to a web-version of the application may force you to re-think some of the way you are doing things. Certainly browsers are intentionally limited in their access to the local file system which introduces a major hurdle for your current mode of operation.
Even if you could display the PDF within a browser, detect the completion of edits and send this back to the server from within browser code (which is probably possible), you'll be subject to different browsers doing different (strange) things with whatever pdf plugin is installed.
As Vitaliy mentioned already, switching being able to populate a (web) form in the browser means that whole download upload problem goes away. But then you have to take what the user has done in a web page and pump that into a PDF somehow. If you don't HAVE to start with a PDF, but could collect the data and produce a PDF at the end then you might have more options. For example you could use iText to create a PDF directly if you don't have too many styles of document to work with. You could use something like Docmosis which you can give templates to and get it to populate and render PDFs later. With the Docmosis option you can also ask Docmosis for the list of fields in the template so could build a web form based on the selected template, let the user fill it in, then push that data to Docmosis to produce the file.
Hopefully there's some options there that are useful to you.
Adobe documents how to do this here. Never underestimate the power of design-by-google. I know this can be made to work because I've used PDF forms on line.
I worked on a similar issue a few years ago, although I wasn't dealing with signed forms. The signature definitely makes it a little more difficult. However, I was able to use iText to create a PDF form with fields, and only submit the field data back to the server. Offhand, I unfortunately do not remember exactly what/how we did it, but can confirm it is doable (with limitations/caveats). Ex: User had to have PDF reader plugin installed & User was forced to d/l the pdf every time.
Basically what I did was use iText to create an FDF from a PDF (with form existing form fields). The submit button in the FDF actually submits the form data to a URL of your choosing (not unlike an HTML form). Once you have that data, I believe I merged the form fields (from the FDF) with the PDF on the server side using iText.
Once you use the server to maintain all the form data, the synchronization/locking process you use to ensure that a single user is updating the latest and greatest form data is up to you.
Your comment under jowierun indicates that you want to deal with word/excel/etc docs as well, so I am not entirely sure I am understanding your needs. Your initial post discussed the needs to fill out PDF forms locally, but afterwards it sounds like you are looking for a file-sharing system instead.
Can you please clarify exactly what you are trying to accomplish?
Requirement is to keep a copy of complete web page at server side same as it is rendered on client browser as past records.These records are revisited.
We are trying to store the html of rendered web page. The html is then rendered using resources like javascript, css and image present at server side. These resources keep on changing. Therefore old records are no longer rendered perfectly.
Is there any other way to solve above? We are also thinking converting it into pdf using IText or apache FOP api but they does not consider javascript effect on page while conversion. Is there any APIs available in java to achieve this?
Till now, no approach working perfectly. Please suggest.
Edit:
In summary,requirement is to create a exact copy of rendered web page at server side to store user activities on that page.
wkhtmltopdf should do this quite nicely for you. It will take a URL, and return a pdf.
code.google.com/p/wkhtmltopdf
Example:
wkhtmltopdf http://www.google.com google.pdf
Depending on just how sophisticated your javascript is, and depending on how faithfully you want to capture what the client saw, you may be undertaking an impossible task.
At a high level, you have the following options:
Keep a copy of everything you send to the client
Get the client to return back exactly whatever it has rendered
Build your system in such a way that you can actually fetch all historical versions of the constituent resources if/when you need to reproduce a browser's view.
You can do #1 using JSP filters etc, but it doesn't address issues like the javascript fetching dynamic html content during rendering on the client.
Getting the client to return what they are seeing (#2) is tricky, and bandwidth intensive.
So I would opt for #3. In order to turn a website that renders dynamic content versioned, you have to do several things. First, all datasources need to versioned too. So any queries would need to specify the version. "Version" can be a timestamp or some generation counter that you maintain. If you are taking this approach, you would also need to ensure that any javascript you feed to the client does not fetch external resources directly. Rather, it should ask for any resources from your system. Your system would in turn fetch the external content (or reuse from a cache).
The answer would depend on the server technology being used to write the HTML. Are you using Java/JSPs or Servlets or some sort of an HTTPResponse object to push the HTML/data to the browser?
If only the CSS/JS/HTML are changing, why don't you just take snapshots of your client-side codebase and store them as website versions?
If other data is involved (like XML/JSON) take a snapshot of those and version that as well. Then the snapshot of the client codebase as mentioned above with the contemporary snapshot of the data should together give you the exact rendering of your website as at that point of time.
A very resource-consuming requirement but...
You haven't written what application server you are using and what framework. If you're generating responces in your own code, you can just store it while generating.
Another possibility is to write a filter, that would wrap servlet's OutputStream and log everything that was written to it, you must just assure your filter is on the top of the hierarchy.
Another, very powerfull, easiest to manage and generic solution, however possibly the most resource-consuming: write transparent proxy server staying between user and application server, that would redirect each call to app server and return exact response, additionally saving each request and response.
If you're storing the html page, why not the references to the js, css, and images too?
I don't know what your implementation is now, but you should create a filesystem with all of the html pages and resources, and create references to the locations in a db. You should be backing up the resources in the filesystem every time you change them!
I use this implementation for an image archive. When a client passes us the url of an image we want to be able to go back and check out exactly what the image was at that time they sent it (since it's a url it can change at any time). I have a script that will download the image as soon as we receive the url, store it in the filesystem, and then store the path to the file in the db along with other various details. This is similar to what you need, just a couple more rows in your table for the js, css, images paths.
I have to create a java applet that needs to access static data which is around 600k in size. This data is exported from an sql database. What is the the best format for that data to be stored in (xml, json, java include file), to get fastest/easiest access to it. I am a complete java noob and this question might be stupid, but is there a way to 'compile' this data in to executable so there are no additional requests to server once the applet is loaded. Thanks in advance!
I do not know what do you mean when you mention 'java include file'.
All the rest is OK. You can use either XML or JSON. It depends on your needs and taste. Just remember that JDK has built-in tools to parse XML and does not have such tools for JSON, so you will have to add external dependency (e.g. GSON). Generally it is not a problem but sometimes code size may be important for applets that are expected to be downloaded from server to client.
The other problems with applets is that unsigned applet cannot write to client's disk. So, whatever format you choose you have to store the information somewhere. You can store it on server, but server has access to DB anyway, so why to create copy?
So, my suggestion is the following. Store data in database. Create server side component (web service) that allows your applet to access the data. Applet should store in browser cookies user id, so next time user runs the applet it enters automatically.
To access browser cookie from applet user live connect and remember that applet tag should have MAYSCRIPT attribute.
If the data is static, just copy in the source tree next to your .java files.
From there, you can access it (from a class in the same package) with:
getClass().getClassLoader().getResourceAsStream("name");
Okay I have a folder say... http://oldserver.net/file/index.jar
How would I be able to protect the file "index.jar" from being downloaded from regular web browsers?
I've seen this done before, I just want to protect it from being accessed from web browsers, and keep it strictly java download access only.
What I mean by java download access only is, I could simply use a java downloader to download index.jar. But I can't download it via web browser.
How would I protect the file "index.jar" ?
Thanks:)
You need to think about what this requirement means specifically - from the point of view of your server, how can it tell whether an incoming request is a "java download" or not?
In short, I don't think there's a way to do exactly what you're after. The classic way to secure resources would be by requiring authentication (i.e. you need a valid username and password to get the index.jar file) but it doesn't sound like that's what you want here.
Bear in mind that Java simply sends HTTP requests (or other protocols that it knows how to speak) down a connection. Any other program could send identical requests, so there's quite simply no way to enforce this limit in the way that you've specified.
One approach that might simulate what you're after is to not have the index.jar accessible via HTTP, so browsers wouldn't be able to get at it by default, and then access it via another protocol in Java (e.g. FTP, SFTP, whatever). Though as mentioned above, any tool that can speak this new protocol would be able to download the file.
Another approach would be to look for Java-specific headers, such as the User-Agent field (assuming this is populated with something recognisable). But again - this is not secure, as any tool could send through the same headers and impersonate a java download.
If you mean in your question that you only want your files to be downloaded by a specific Java application, then things get a bit more feasible. You can distribute an application that contains some authentication (e.g. public/private key pair) and have the server challenge for this when index.jar is requested. But even then this is dubious - by definition the Java app has to contain sufficient information to authenticate as itself; and by definition you have to distribute this information publically; so it wouldn't be difficult to extract the private keys and have some other application masquerade as your Java one.
Basically, I can't see any way around this issue given the confines you've stated. If there's a narrower scope you'd be willing to entertain you may be able to come up with a viable compromise, but right now the answer is simply "no".
Technically, you can't. Whatever request HTTP Java makes, another HTTP client program can be made that makes the same.
However, you can make it slightly more difficult. You can put the file behind HTTP digest authentication and include the password in the JAR of the Java program the password or can check the user agent server-side.
See e.g. get_browser() and Apache 2 authorization and authentication.
You can make your file read only so that no one can modify actual file but there comes a problem that even java cant modify the file.
So if you need to modify the file,you need to make a new file of same extension and copy entire data from main file to new file and delete the main file and modify the new file and change the name of new file to old file name.
There is a function in java to set read only:
File newTempFile=new File("mytext.txt");
newTempFile.setReadOnly();
You could create a web application that serves your file. Here you could check for the user agent string in the request and decide on that user agent string whether to serve the file or not. For this to work, your "java downloader" must have an identifiable user agent string and your application must "know" it.
Of course any bad guy who knows this, could make his browser send you the same user agent string, so this in not really secure :-/
If your index.jar is very important, do not make it available for download in any of the methods mentioned. As soon as it is available for download and ends up on the client computer, inside java or not, it will be hacked.
Some code should only run on the server.