I am a relatively newbie to Lotus/Domino world and have been tasked with the following Domino task.
Access user's Domino mailbox (from a middleware server) and delete certain malicious emails from the same.
Additional Background: There is a external security tool/process that analyzes all incoming email and can flag the email as malicious. In the event it is flagged as malicious then I want to delete this email from the respective user's inbox.
My solution would be deployed on its own middleware server (Linux based) and will receive incoming notifications as to what emails need to be deleted.
The Domino server deployed in my environment is Lotus/Domino 9.
I want to preferably implement this functionality using Java.
I researched and found the potential options for me for accessing the user's inbox on Domino server.
1) I saw that there is a IBM C/C++ API toolkit for Domino. The C API looks quite complicated to me on first glance. Also I would need to install the Notes client (on my middleware server) so that I could invoke the C API remotely?
2) Is there a Java API that I could use to connect/access Domino? I found:
IBM Knowledge Center - IBM Domino Designer 9.0.1 - API Documentation and
IBM Notes and Domino Application Development wiki.
These seem to indicate there is some Java/REST API interface however I am not sure if I can use this to access inbox/mailbox data. It seems to indicate "Calendar" data but nothing about email/mailbox data as such.
3) I came across the OpenNTF Domino API project while researching and that seems to have a Java API. Should I be using this?
What is the best way to access Domino from an external server standpoint? Am I stuck with the C/C++ API or is there a relatively (easier to understand and use) REST/Java API that I could leverage? Also will I have to have the Notes client installed on my middleware server so that I can invoke the API (C/C++ or Java)?
You should avoid the Notes C and C++ APIs unless:
You know Lotus Notes and Domino really, really well (or are willing to learn a lot very quickly) and
You determine that the only way to solve your problem would be to write a Domino server task or extension. These APIs work with Lotus Notes/Domino data a very low level.
Yes, there is a Java API. It's been around for years. There is also a REST API that can be accessed from Java (or from any other language that can make HTTP connections) but that's only been around for a few years.
The Java API is richer and can get to a lower level than the REST API.
The REST API might be adequate for what you need, but there's a very good chance that the server will have to be set up specifically to enable it to access the mailboxes. That will not necessarily be the case if you use the Java API.
Using Java API will depend on whether you can run your Java code on a machine that has the core Lotus Notes/Domino code installed. Also you'll have to investigate the technical and licensing questions on that.
A good way to get educated on the Java API is to read Bob Balaban's book. It is old and out of date, but it does cover most of what you need to know for the purpose you've described. One caveat is that it was written so early that it did not cover the need for making recycle() calls. But he's posted the chapters here for free download. Now that you know about recycle() I'm sure you can find information about why and when you need it.
The OpenNTF Domino API is an open source replacement for the offical Java API. It has been built to solve a lot of really nagging problems (like recycle()!) and the limitations usage of the official API runs into.
Re: installing the Notes client which I alluded to that when I mentioned the core Lotus Notes/Domino code under point 2. You have two options for the official Java API:
Local:
This uses the core Notes/Domino code to make Notes RPC calls to the server, so you will have to install a licensed version of the Notes client or Domino server code to get the core code.
Note that if you are tied to a 64-bit JVM, you need 64-bit code and that means you need to install the Domino server instead of the Notes client since there is no 64 bit Notes client.
Remote:
You don't need to install any Notes or Domino code but this uses CORBA/IIOP instead of Notes RPC to talk to the server. This requires enabling IIOP on the Domino server.
The last time I checked, the OpenNTF API only supports the "Local" model.
I do have to mention though: this is close to being off topic for this reason:
Questions asking us to recommend or find a book, tool, software
library, tutorial or other off-site resource are off-topic for Stack
Overflow as they tend to attract opinionated answers and spam.
Instead, describe the problem and what has been done so far to solve
it.
Whilst the existence of a Java API can be easily confirmed by searching here on StackOverflow, I have to admit that finding basic references for Domino is quite a bit more challenging. There is literally 25 years worth of information about it that's out there, but is often in fragments and is obsolete. It is really difficult to find information about tools, APIs and libraries that are available and current today. The options are really pretty limited.
As such I think this question deserves an answer since it does not really come down to opinion. I'm not going to make a recommendation though, because that really would be opinion.
Related
I need to create digital signature of some XML data with a client certificate(smart card) using web browser. Usually I used to do it with a java applet executing on the client side. The benefit being multiplatform in terms of OS and browsers.
However this option is getting increasingly harder and harder to implement and support in the long term. Virtually all browsers require some sort of action in order to execute such applet, code signing with a trusted certificate is almost mandatory nowadays, new manifest attributes and so on. Well there is nothing wrong with some extra layer of security and I am ok with that.
However Google Chrome as of April 2015 has stopped support for Java applets (and other plugins as well) - there is a configuration switch but it won't be available for much longer as stated here.
Mozilla Firefox does not have end of support date for NPAPI but they call it "legacy technology".
As for IE - it does not support plugins in Modern UI.
So with Java applets no longer really a universal option what are my choices?
What I have investigated so far:
ActiveX - IE only
Silverlight - no access to certificates at all and as a plugin faces the same limitations as Java
Browser specific extensions; For example Firefox up until version 33 used to have window.crypto.signText but not anymore
local applications installed on the client - not easy to install, support, develop and update for several OS and their different versions.
Web Cryptography - "only basic cryptographic functions", no certificates support
I ran out of ideas. All suggestions are welcome and appreciated.
I did same research few weeks ago, and the first option for me is migrate to firefox (at least for now).
An alternative, could be migrate applets to JNLP java client application (maybe with some websocket/restful synchronization between java client/server/web page).
I think the options that you mentioned have less support among browsers than java applet.
Proprietary API available
I want to revive an answer previously deleted for lack of information. My answer does not provide complete info but since I had the same problem and stumbled upon this question, I'd like to share my findings.
I also have an additional requirement so that the browser signature works on "older" (IE9) browsers.
There is a web API at https://www.4identity.eu/ distributed by Italian smart card manufacturer Bit4id.
The 4identity API, however, is not really a full "web API" that relies on plain Javascript, as it still requires to download a Windows-only client (sic!). The client, as far as I could understand, responds on a custom keychain URL protocol (I had a past Oauth-2 related question on how to handle desktop applications....) which is not standard according to my findings. The client has access to the key store so it can upload the signed file to the remote web service who is being polled by the Ajax page.
I need to do some paperwork to get full API access, and I have no information about pricing. Still, I deem worth to give a detailed look.
Part 2 of the question
Supporting a real digital signature from browser requires browser vendors and W3C, who oversees web standards, to do a lot of effort, maybe just the same effort they did for standardizing DRM solutions in HTML5 for sake of multimedia companies (criticism mode on). Currently there is WebCrypto standard but according to research it is not available in "mainstream browsers"
Digital signing a remote file with a smart card requires access to the key store and the implementation of cryptography libraries. An open source implementation of PaDES/CaDES is expectable by the community, but without a final implementation of a standard way to access the key store the smart card cannot be accessed.
See also this answer.
This additional part of the answer does not apply to my case as I require this to work on older browsers.
Disclaimer: I am not affiliated with Bit4id but I know them since I had the opportunity to integrate their work in my apps. One of our customers is a Bit4id partner
I am working on an Android app using Android Studio v 1.4 and the minimum sdk version is 14 and what I am trying to do is building a simple VPN client that implements PPTP and L2TP protocols.
I have googled and searched here in Stack Overflow and I have looked at the Android sdk VPN sample called toyvpn and also looked at the official documentation for the VPN Service class.
How to implement PPTP or L2TP with VpnService on Android Platform?
Is there any code samples,libraries or even a starting point to such an implementation.
The question is an interesting one. There is a fundamental flaw though in how it is phrased. I think the question is too general. However, I still think it is useful for direction.
First as others are saying VPN's are very complicated and I am sure many others would recommend not taking that on. However, there are many solutions for your needs. You mention PPTP.
"Don’t use PPTP. Point-to-point tunneling protocol is a common protocol because it’s been implemented in Windows in various forms since Windows 95. PPTP has many known security issues..." taken from this article.
The going recomendation is to use OpenVPN. Now if you go to their site they ofter already built software at a price. I assume this is not what you are looking for in the end.
What you can do is leverage the OpenVPN libraries and build it out yourself. Since it is opensource you can use the libraries for your benefit but you have to do the implementation work. What I have found for you is the GitHub repository where OpenVPN is leveraged in Android.
Source
I would certainly take a look here. It is probably a useful example that you can build from. This way you can come back and ask code specific questions if you are hitting a wall.
Lastly, VPN's are a two way street. Having it on the Android( client ) side still requires a server side implementation. So I would also think this article would be a beneficial part of the learning process.
I hope this helps.
I am looking to query LDAP server to retrieve all the user entries from it. I have come across some libraries
OpenLDAP
LDAP SDK
Mozilla Directory
Apache Directory API
My requirements would be to query all users in an LDAP implementation like AD Server, ease of programming and good community around the library. I don't find a clear winner here. Can someone tell me the widely used and robust API?
The best API to use with Java is the UnboundID LDAP SDK. It's clear, complete, fully implements the LDAP standard specification, easy-to-use and understand, fully documented, thread-safe where it should be, and the standard edition is free. No other API even comes close.
see also
LDAP Examples using the UnboundID LDAP SDK
Had to dive into Java LDAP SDK market, as some old LDAP JAVA programs with SDK bugs needed to be fixed and I had lost up-to-date overview of supported Java LDAP APIs for a while. A little research has brought me to several aged overviews and this rather old thread. I thought, I'd just share my more-up-to-date SDK findings here.
As of today, this is what the Java LDAP SDK market seems to offer:
jLDAP (Novell Java LDAP SDK),
OpenLDAP Java SDK (sibling fork of Novell LDAP SDK),
Netscape/Sun Java LDAP SDK,
OpenDS LDAP SDK: All 4 repositories seem practically dead/unmaintained for several years (some of them for a decade now) now. No backing companies or active communities in sight.
Oracle LDAP SDK: Basically the former Netscape/Sun Java SDK with paid Oracle support, but otherwise not maintained either. Does not even exist in the open source world.
OpenDJ Java LDAP SDK: The backing company has moved away from the open source market, no longer maintain this SDK. The most recent SDK version 3.0.0 is already several years old and never left beta stage, the latest official release version is even older: 2.6.11. The commercial version of the SDK is said to be practically abandonned either.
ldaptive.org: some university project. A former JNDI wrapper, but now claims to have an own LDAP SDK protocol implementation. There seem to be no community or users outside of the university perimeter. Not dead, but currently unclear, what quality state to expect here. If you'd ask me, this project would have done a lot better, to spend their time backing the Apache LDAP SDK project, as no one actually needs yet another look-mom-I-also-made-an LDAP-Client-SDK in an a saturated market full of other mostly mediocre JAVA LDAP SDKs.
Apache LDAP SDK: Compared to other Apache projects, the LDAP SDK shows really slow pace. Somehow Apache LDAP seems to miss a real company backing things, it's only talented hobby enthusiasts pusing things forward. You probably do not want to start any new projects with SDK V1.0, as they state that V2.0 breaks interface code. but you probably also do not want to use SDK V2.0 yet, as it's still beta and no one knows for how much longer it will stay beta (V1 stayed beta for 6 years...). The SDK is far from being dead, it's just showing really really slow progress.
Java JNDI: Built into Java since ages and has not changed since release. Still is really ugly for coding, documentation is a mess, every task beyond basic search is an implementation nightmare, basically every project fails to properly implement it, several things are broken by design. There seem to have been a few concept ideas of a JNDI-LDAP-successor for a future JDK, but nothing has ever followed so far.
Unbound SDK: Mature, best maintained SDK, has huge amount of features, though the backing company is still nurtured from venture capital, burning money. So far it does not look like they stand on their own feet any time soon. So the long term aspect of SDK backing support is unclear. A former party pooper for the SDK in commercial projects once was its GPL license. The open source version now seems to have a LGPL license as well (that may or may not fit a project).
Spring: seems like a stable LDAP SDK, plus has the large Spring community. But less feature-rich and no bleeding edge stuff. Personally no experience yet though with this SDK.
So right now, Java LDAP seem to have a reasonable choice of four: JNDI, Unbound, Spring, Apache, each with their pros and cons. And you probably will hate JNDI a lot, as soon as you start using it.
A good advice might be, to not rush into migration projects of old SDKs and to invest into the extra effort of implementing wrapper code, to be at all able to easily switch the SDK later when needed.
Check the Apache Directory Client API it is opensource and has an active community (full disclosure: I work on Apache Directory project) and most importantly Apache Directory Client supports all basic LDAP controls including password policy and syncrepl by default unlike some commercial versions which support these in a paid version only.
You can easily add new/custom controls and extended operations if needed and it is very easy to start an in-memory Directory Server with the help of the annotation driven test framework
Take a look at this example to see how you can leverage the API and test framework for unit testing.
And otoh, if you ever need a Kerberos v5 server in your unit test, it is just an annotation away.
We use the the UnboundID LDAP SDK. It is very good and there are many examples and good support.
Poor support and maintenance for the JLDAP and Mozilla Directory APIs is why we QUIT using them.
Like the https://wiki.mozilla.org/LDAP_Java_SDK does not exist.
The JLDP sdk has not been updated in YEARS. (2009 as I recall).
There is also open source lib from Imperva https://github.com/imperva/domain-directory-controller
There You can find a pretty good examples of queries.
I'm using https://www.ldaptive.org/ in production, so far I'm pleased it's like 'ORM'
I'm reading up on my upcoming project that involves using my laptop's TPM on authentication software written in Java.
A few entries came out on Google, but most of them are quite old, and I have no idea which is the best tutorial. So I'd like to know what's the recommended API to use, and where is the best place to get information from.
Thanks.
To communicate with a TPM you need a Trusted Software Stack (TSS). There are two major freely available TSS: TrouSerS and jTSS.
jTSS is written in Java, whereas TrouSerS is written in C.
When using the pure Java jTSS you don't need jTSSWrapper. The wrapper is only needed when you want to access TrouSerS TSS through Java.
The jTpm Tools provide some command line tools to interact with the TPM. When looking at the source code of the tools you can figure out how to use jTSS API.
For more stuff related to Trusted Computing and Java have a look at http://trustedjava.sourceforge.net/
There's also a JSR that tries to define a high-level Java API for Trusted Computing, you can find the information as well as a reference implementation at http://jsr321.java.net/ (including public readable SVN repo).
start reading here.
http://trustedjava.sourceforge.net/
There is any Information you need. To access your TPM (I would suggest you to do first tests with the famous TPM Emulator from http://tpm-emulator.berlios.de/)
In Java you need the Package jTSSWrapper. Just look at the test-code insight the package to get a very first impression.
I'm currently in the research phase of my dissertation project.
My project is a ticket booking system for a mobile device and I have chosen to target Android.
I anticipate the need for a client/server architecture with a central server, and so am currently looking at how Android could communicate with such a server. The server would grant the client access to ticketing information, and the client would send information about ticket bookings to the server. I'm looking at Java EE for the server as Java is the language I'm most experienced with.
I'm aware that Android comes with java.nio and java.net, as well as some org.apache packages, but am also looking for libraries/technologies that would be possible to use with Android.
So far I've not found anything massively helpful on the internet, so I'm seeing what SO can suggest.
Specifically I am interested in knowing:
What support is there for various middleware technologies in Android? e.g.
RPC based middleware
CORBA
Message based middleware
Web services such as XML-RPC, SOAP, REST
How well (or not) do existing Java libraries work when used on the Android platform? (e.g. If I wanted to use a library/API designed for Java SE rather than Android what problems might I encounter?)
Ideally, as the focus of my project isn't meant to be the communication between the server and client, I could use an existing middleware to handle the communication, but I am prepared for the worst case, which is having to write my own.
What support is there for various
middleware technologies in Android?
My personal opinion -- though I do not feel I am alone in thinking this way -- is that only protocols specifically designed to run over the Internet are remotely suitable for use with a mobile client. So, of your list, the only one that I would even entertain would be:
Web services such as XML-RPC, SOAP, REST
Some people have been maintaining an Android port of kSOAP2. However, I get the distinct impression that most Android developers working in this area have tended towards REST and REST-ish protocols. If nothing else, that's what all the fun Web sites and services are using for an API, particularly compared with XML-RPC (old) and SOAP (old and icky).
I have successfully used both the java.net.URLConnection and Apache HTTPClient libraries in Android for communicating with REST-style endpoints -- both directly and through third-party JARs -- with no real Android-specific issues.
How well (or not) do existing Java
libraries work when used on the
Android platform?
It is difficult to answer that in the abstract. Android implements a substantial subset of JavaSE, but not all of JavaSE, so there's a chance that any given JAR will expect something Android does not offer. Similarly, Android does not use environment variables, command-line switches, or a variety of other things that developers focused on the desktop might have introduced as semi-requirements. So, some things have worked for me with nothing more than a recompile (Beanshell), and some things have worked for me after removing redundant classs (JTwitter), and some things looked like they were going to be ghastly to get working (JavaMail).