I have a windows service written in .NET/C# which reads emails from a Domino mailbox. Currently I am using the Lotus Notes .NET Interop to achieve this. However for this the Lotus Notes Client needs to be installed on the server. I am trying to find a way in which I can achieve this without having to install the Lotus Client on the server. From whatever I have read, I did not find anything.
Proposion N2N is an ADO.NET provider for Domino, but even that needs the client to be installed on the server.
Is there a solution available for this?
In a word, no.
You don't need all of the Notes client (or Domino server) install to get to the data, but you do need a significant part of it (and an ID that has access). Even if you take nothing else into account at all, you'd need a "driver" that recognises and can read all of the various ODS (on-disk structure) versions your database might be in, and it has to be able to handle both stored MIME and Notes Rich Text composite data structures with LMBCS (Lotus Multibyte Character Strings). Neither of those tasks is trivial. Then there's the security to get around: most document data are not stored in the clear even if the database is not locally encrypted (which only prevents unauthorized access from within a Notes/Domino environment if the ID for which it has been encrypted has not been compromised) and the storage method is not published.
In other words, you'd need something that is most of Notes in order to read and/or write, and the easiest way to get most of Notes is to install Notes.
Related
We have a requirement to access an application built on Lotus Notes script. We need to automate / use this application from outside. This application can be accessed using Lotus Notes client.
Is it possible to access this application using Interop.Domino or is there any other way?
Thanks.
This depends on what you mean by "automate / use".
Interop.Domino is an interface to the Domino COM classes: Lotus.NotesSession, Lotus.NotesDatabase, Lotus.NotesDocument etc. These classes can access the data that is stored by your application. I.e., they can read, write and delete the documents stored in the application's database (NSF file).
What Interop.Domino cannot do is automate the application, by which I mean that it cannot drive the application's user interface, display views and forms, enter data into visible fields, click buttons, etc. If that is what you want to do, then you need to use the Lotus Notes OLE classes: Notes.NotesUIWorkspace, Notes.NotesUIDatabase, Notes.NotesUIDocument, etc.
BTW: The answer to your question might also depend on what you mean by "from outside". One important thing to know about both the Interop and OLE classes is that they require an installed Lotus Notes client or Lotus Domino server on the machine they are running on. So if "from outside" means that you want to access the application from a machine that does not have a Notes client installed, then what you're probably going to have to do is install your code on a Domino server and provide a mechanism (e.g., a web interface) for your users to interact with it.
Is there anyway to prevent people from using Reflector.net to decompile my .exe c# application? I know there is a tons of post about this but I don't really care if people can see my code the only thing I want to "hide" is my database connection string.
I am currently using "Settings" in my c# to keep the database connection's info.
I wanted to know if using those string in my project's Settings would prevent people from seeing it ?
I am using DotFuscator in visual studio 2008 but I heard it wasn't preventing people from decompiling my program.
I know I could use a Web Services but my server will be on linux so I guess I can't store web services on Linux.
No. Even if you encrypt the connection string in the program code or in a settings file, you will need to decrypt it, and the program must necessarily contain the decryption key somewhere, which means that someone who is interested enough in finding it will find it, no matter how creative you are in hiding it. Why do you need to hide the connection string? If you are afraid that someone who has your program might call the web services directly and trigger unintended actions, you should look into how the web services are structured, what they allow clients to do, and how the authorization works, and make security improvements there instead.
If your program has the connection string in it, users of your program can get it back out. Even if you encrypt it, they can sniff it when your program connects to the DB server.
If you don't want your users to know your DB login credentials, don't give your DB login credentials to the users. That's the only way.
You could do this by instead giving each user their own credentials, and using the permissions system in the DB server to control what they can or can not do.
As others have stated obfuscation is no real protection for a connection string stored in a client application where the user have access to the binaries.
Don't use a direct database connection from your program unless the user is trusted to use the database directly with the same privileges. Have a service (web service, REST-service, etc) in between that you host on your own server. Linux can host services of any of those types I mentioned (use Mono if you want them in .NET on Linux)
In order to expose your database via a web service using Mono or any other language/framework you can host on Linux you would create a web service method for each atomic operation you want to perform against the database.
An additional advantage over letting the client application access the database directly is that when the client application is using a service between itself and the database you are free to change your data store without affecting the client. You can decide to change the database schema in your database or replace the database with a NOSQL solution or even a flat file.
Having a service instead of communicating directly with the database moves the authentication/authorization requirement one step, so now you need to implement it in the service. Fortunately there is rich support for authentication in a web service.
Take a look at this guide on this specific topic from MSDN. Keep in mind, however that this only shifts the security burned. Now you need to manage the security of the key
I am trying to create a document manager for my winforms application. It is not web-based.
I would like to be able to allow users to "attach" documents to various entities (personnel, companies, work orders, tasks, batch parts etc) in my application.
After lots of research I have made the decision to use the file system to store the files instead of a blob in SQL. I will set up a folder to store all the files, but I will store the document information (filepath, uploaded by, changed by, revision etc) in parent-child relationship with the entity in an sql database.
I only want users to be able to work with the documents through the application to prevent the files and database records getting out of sync. I some how need to protect the document folder from normal users but at the same time allow the application to work with it. My original thoughts were to set the application up with the only username and password with access to the folder and use impersonation to login to the folder and work with the files. From feedback in a recent thread I started I now believe this was not a good idea, and working with impersonation has been a headache.
I also thought about using a webservice but some of our clients just run the application on there laptops with no windows server. Most are using windows server or citrix/windows server.
What would be the best way to set this up so that only the application handles the documents?
I know you said you read about blobs but are you aware of the FILESTREAM options in SQL Server 2008 and onwards? Basically rather than saving blobs into your database which isn't always a good idea you can instead save the blobs to the NTFS file system using transactional NTFS. This to me sounds like exactly what you are trying to achieve.
All the file access security would be handled through SQL server (as it would be the only thing needing access to the folder) and you don't need to write your own logic for adding and removing files from the file system. To remove a file from the file system you just delete the related record in the sql server table and it handles removing it from the file system.
See:
http://technet.microsoft.com/en-us/library/bb933993.aspx
Option 1 (Easy): Security through Obscurity
Give everyone read (and write as appropriate) access to your document directories. Save your document 'path' as the full URI (\\servername\dir1\dir2\dir3\file.ext) so that your users can access the files, but they're not immediately available if someone goes wandering through their mapped drives.
Option 2 (Harder): Serve the File from SQL Server
You can use either a CLR function or SQLDMO to read the file from disk, present it as a varbinary field and reconstruct it at the client side. Upside is that your users will see a copy, not the real thing; makes viewing safer, editing and saving harder.
Enjoy! ;-)
I'd go with these options, in no particular order.
Create a folder on the server that's not accessible to users. Have a web service running on the server (either using IIS, or standalone WCF app) that has a method to upload & download files. Your web service should manage the directory where the files are being stored. The SQL database should have all the necessary metadata to find the documents. In this manner, only your app can get access to these files. Thus the users could only see the docs via the app.
I can see that you chose to store the documents on the file system. I wrote a similar system (e.g. attachments to customers/orders/sales people/etc...) except that I am storing it in SQL Server. It actually works pretty well. I initially worried that so much data is going to slowdown the database, but that turned out to be not the case. It's working great. The only advice I can give if you take this route is to create a separate database for all your attachments. Why? Because if you want to get a copy of the RDBMS for your local testing, you do not want to be copying a 300GB database that's made up of 1GB of actual data and 299GB of attachments.
You mentioned that some of your users will be carrying laptops. In that case, they might not be connected to the LAN. If that is the case, I'd consider storing the files (and maybe metadata itself) in the cloud (EC2, Azure, Rackspace, etc...).
Hi i am trying to find the best way (or a good one) to store a ConnectionString (my App will connect to a Database in a Server, it will work with it continuosly) and how to handle with the Admin account. For default all the applications with Login must have an Admin account, right?
I think in that way...
So, you install an App on the Machine, how you will configure the ConnectionString? I think that is wrong asking the user to configure such thing if doesn't understand what it is or it really have to be?
And imagine one day that the ConnectionString have to be changed for any reason, if the Admin acoount credentials to Log in the App are in a Table in the Server, how then it will possible to Log in the App to change the ConnectionString?
This is my problem now... I don't know how this type of things is handled, if are there any rules to handle this, any common way because i am starting to work more seriously with this type of things.
Note: I think that is not important but my App is being developed in WPF.
A really easy way to do DB access security with MS SQL Server is use "Integrated Security = SSPI". With that, MS SQL server authenticates against the Windows user entity under which the database accessing process runs. It all happens seemlessly using MS SQL Windows Authentication without the need to store any usernames or passwords within the application.
Another way to do it is to distribute a config file with the database connection string in it, with at least the password encrypted.
We have many MySQL databases on several servers too, so MS SQL SSPI doesn't cover us.
For server side software I store database connection strings and credentials in a separate XML config file that all the server side software uses. The credentials are arranged topically with all database information encrypted. I use a common file for all the server processes and developed a little encryption / DB config file management GUI so management is simplified and access is universal to all the software using the same code.
For end user software it is too difficult to maintain with local config files because of user maintenance. For "fat client" software I maintain a separate database with encrypted credentials on a server in our DMZ that is universally accessible to anyone havinng that software (there is not that much distributed fat client software.) Our web app software has a consolidated user database that controls access for all users/roles for all apps, and everything is portaled through the one system so it is far easier to mantain the user database.
Frankly, the polyglot system is increasingly ugly to maintain. I would use our main domain LDAP server (Windows ADS), but our company policies keep ALL domain member servers completely firewalled off from access outside our most trusted VPN and thus inaccessible in too many circumstances.
I hope someday to have time to setup a *nix based LDAP server in our DMZ and centralize all credential information there.
With connection strings to a MS SQL server you basically have two options:
Either store a username/password pair in it. Your application has to be able to read it, so theoretically, any user of the application could do the same (he has access to your application, so he can decompile it). Practically, you can encrypt the connection string, with a key stored in your source code or application resources and be quite confident that your users won't be able to read the password.
If you have some users that should be able to use the application and you believe them, and other users that may have access to your application but that shouldn't be able to use it, you can use Windows Authentication, and set Integrated Security=True in your connection string. This assumes you configure your DB, so that the approved users have access to it.
Either way, your connection string should be bundled with the rest of the application. If you ever need to change it, you just release a new version. (This works even for the most primitive version of installation: “copy this bunch of files to a directory on your computer”).
Now, the connection string can be stored pretty much anywhere, the most convenient place probably being application settings file.
If you want to be certain that your users will be able to use only the functionality provided by your application and not access the database directly, you'd have to write something like a web service and connect to the database only indirectly through that.
If you need to store the connection string in a configuration file or somewhere else of your choosing, you might want to encrypt and base 64 encode the encrypted results back into a string. Check here for an Encrypt() and Decrypt() implementation.
It is possible to manipulate files (such as the .config file) during the install of the application. So it is acceptable to ask the user/admin (during setup) for the name of the server (and even for a user name and password provided you encrypt these but I'd rather use integrated security).
For updates of the connection string just make a new installer.
Alternative: store the connection string in active directory or in an other well-known store so all you need to do is change the value in one place.
Currently i can access nsf all nsg files.But once i uninstall Lotus Notes form my machine program doesn't work.
I am using "Introp.Domino.dll".
Language: C#
I did this a long time ago, and if I remember it correctly it's not possible to use the Introp.Domino.dll without the Notes client installed.
A solution is to parse the xml returned when you add the " ?ReadViewEntries " to the nsf url.
youdominoserver/names.nsf?ReadViewEntries
Good luck,
rAyt
If you don't have Lotus Notes installed then the only way to get access is to connect to a Domino server. There a couple of ways (if using C#).
HTTP Examples.
server/database.nsf/viewName?readviewentries
server/database.nsf/viewName?readviewentries&OutputFormat=JSON
server/database.nsf/viewName/docname?OpenDocument
server/database.nsf/agentName?OpenAgent&variable=xxx
docName above would be the value of column 1 in the view for that item. You can also access using the UNID of each item. More examples on the Domino wiki.
Web Services
Domino 7.x and later supports Web Service providers. 8.x supports Providers and consumers. Example.
server/database.nsf/webService?WSDL
server/database.nsf/webService?OpenWebService