Public Domino server has a publicly available Lotus Notes database. That database has a form that an unauthenticated user can fill out and submit using his/her browser.
This publicly available form is only used for the post request and data must not be stored on that publicly available server. Instead, I need to connect to a database on an internal server and create the document there.
Obvious solution is a Lotus Script agent but when I worked on Notes, I remember non-user agents were prevented from opening databases on another server for security reasons. I certainly cannot introduce secure server setup. I need to find a way to do this that fits current setup. The servers are in two different Notes networks but mail is routed between them, so if I don't find a better solution, I will probably mail the document.
Any ideas? I have not worked with latest Notes servers. Anything in 8.5 that can help here?
In the server document on the security tab there is an Option called "Trusted Servers" if you could put the external server into that field, then the agent would be allowed to dirctly write into databases on the internal server.
If you are not able / allowed to do this, then you have to write to a "local" database (on external server) and replicate this database to internal server either by using a console command (NotesSession.SendConsoleCommand) or with the replicate method of the NotesDatabase class (not sure, if this will work due to the same security restrictions) or via scheduled replication.
If the database itself cannot be replicated on the external server, then you should use a container database and let an agent on the internal server copy the data to the internal database.
And the last possibility you already mentioned: compose the document and send it via mail. Make the target database a mailin- database and simply send you data there with NotesDocument.Send...
One of these options should solve your problem.
Related
I have created this assignment where I am essentially using .net Core to read and write to an instance of a SQL localDb: Github
This is my first time using a localdb, but when I submitted it to my professor, he is not able to create, or manipulate the database at all. My thoughts were that when he runs it, it would create and instance of the database on his computer, but I guess not. He gets the following error:
SqlException: Cannot open database 'Bartender_App' requested by login. The Login failed. Login failed for user "Username"
this error occurs when trying to create a new order. Is there any way to bypass this authentication? because the web app works on my computer.
would he have to create his own migrations and update the database from Visual Studios on his end?
I have tried to look it up, but come across deployment of these web apps to a server which is not what I am trying to do, I am just aiming for him to be able to run the application on his computer, even if the database starts empty, and he can manipulate, add, and remove the data from the localDb instance
I apologize in advance for the tags - the autocomplete feature was not showing up correctly.
Is there any way to bypass this authentication? because the web app
works on my computer.
This is impossible, SQL Server Express LocalDB does not accept remote connections.
As an alternative, you can automate the backup of your database structure and provide it to your instructor, you can refer to How to copy a database from one computer to another?.
If there is not much table, manual creation may be faster and easier.
More details ,have a look for Can SQL Server Express LocalDB be connected to remotely?.
We have a purchased commercial app that accesses a named, locally installed SQL server instance.
Is there any way for us to transparently move the DB to a remote shared SQL Server host, but still have things configured within SQL Server so that the local software can access as it it were a local instance?
Keep in mind, since it's a purchased software package, I don't have the ability to modify the queries it's running, so if tables have to change into fully qualified, or other special T-SQL syntax to make this work, it's not an option.
Effectively, we need to "trick" the app to use a remote database, but access as if it's a local instance (though configuration, some sort of proxy, or perhaps dark magic).
The total extent of the application DB configuration settings is to select the name of the local instance to connect, as shown in this image: .
SQL server is installed on the local machine (Win2012R2x64), and has a couple instances running. I have complete control of both local & remote SQL servers, so can make unrestricted config changes to them. Current DB version is SQL2014, but could upgrade to newer if newer version features are needed to do this.
You can try creating an alias to the remote sqlserver from the local sql server. (Via Sql Server Configuration Manager | Aliases | Add a new Alias name)
Your local instance alias should be the name server name that the connection string is using to connect.
I've used this method in the past to change the sql instance that I was connecting to without changing any connection string info.
More info here
It depends what sort of access the commercial app needs in the locally installed database once the app has set up and created its database.
You will probably invalidate any support agreements in the attempt. Worse still, if a commercial app insists on a local instance then I dread to think what security horrors it will insist upon in your shared instance.
You need to profile the database while the functionality of the application is used to find out what it does and how it does it. Even if you determine that the security permissions could be greatly restricted you may find that the app checks to see if it has a higher permission level.
I've no way to hand of testing this approach but....
Install the app as usual which will be on your local instance
Back up the DB on your local instance and restore the DB to your remote instance. Remember to set up what logins are necessary.
Set up a linked server to on your local instance to your remote instance.
Delete all objects in your local DB instance
Create sysnonyms for all objects pointing at the remote instance.
If it is an application that simply requires direct table access this might work. It is however an ABOMINATION.
I am looking to create a database server that can be used to store data using a VB.net application. When I initially installed SQL Server 2005 Express edition, I believe I installed this using the LocalDB option.
As it stands my application is a simple tool which utilises the Process.Start command under certain situations, depending on user input, to launch Game Servers for use at a gaming LAN I assist in running.
I wish to progress the application by being able to update, delete and query a database created in SQL Server 2005 Express. I understand the use of connection strings etc, however I am wondering if the installation using LocalDB will mean that I cannot connect to the server to process the data I require.
Can I continue to use the LocalDB option and create a Database Server for specific use using my application or is a different installation option required?
Secondly, can someone point me in the right direction of how to create a new Server for this purpose? All of my searches so far have provided results for creating a database only, and not the server.
I have a couple questions about what you are trying to do.
First, why are you installing SQL Server 2005? It was released almost a decade ago.
I would go with 2012 express edition.
http://www.microsoft.com/en-us/download/details.aspx?id=29062
Second, install the management tools. SSMS is a nice GUI to do work in.
Third, If you are spinning up anything other than express, there are licensing costs which are quite high. 9K for standard and 25K for enterprise per socket or such.
Here are the versions and features list from microsoft.
http://technet.microsoft.com/en-us/library/ms144275.aspx
Last but not least, having the express edition on another computer is fine. However, you will have to use a network protocol such as TCP/IP instead of shared memory.
It will take longer to send Tabular Data Stream (TDS) to the other computer versus talking to memory on the same computer.
http://social.msdn.microsoft.com/Forums/sqlserver/en-US/c4f06669-41fd-42e6-b4a9-564cf04ca9f7/how-to-choose-between-shared-memory-named-pipes-tcpip-via?forum=sqlgetstarted
Good luck with your project.
You can use a local instance of SQL Server just fine, if you want to set up a separate server for some reason then you'll need either a 2nd machine on which to install SQL Server, or to spin up a virtual machine. If running Windows 8 (and barring hardware limitations) you have Hyper-V at your fingertips.
This is not a complete answer for you but may give you some things to think about.
First you might want to think about your choice of database. If you don't have a compelling reason for using 2005 you will probably at least want to move to SQL Express 2008.
Second, to answer the part about creating a server... A server is something that serves data. In a general sense a computer configured to be contacted by external machines and respond with data is a server. A web server runs a program like IIS or Apache to respond with web pages. A database server contains a database and allows connections to that database. So as long as you install the database on a computer and configure it to allow external connections, you have your database server.
In MS SQL there are several things that need to be set up to allow a database to accept external connections. One is that the SQL Server Browser service will need to be active. Another is that the database itself will need to be configured to allow external connections (SQL Authentication type probably).
Hope this helps.
Addition:
SQL Remote Connection Configuration
Disclaimer, I don't have SQL Express 2005 installed but I think the settings are found in the same place in 2008. If the info here is not exact to SQL Express 2005, the general terminology used here should be enough to get you headed in the right direction to find the specifics.
While viewing the database in Server Management Studio or Enterprise Manager, right click the database server instance name (the root of the tree) and select properties. There should be a section title Connections and within this section there should be an option "Allow remote connections to this server". Make sure it is checked. The other setting you need in this properties menu is under the security area. There is a radio button for "Windows Authentication Mode" and "SQL Server and Windows Authentication Mode", you want the second that allows both.
The next step you have may be to create a new user, add a password, and connect the user to the database. That will give you the credentials you will use in your database connection string while programming. I usually add new users through the security section of the database then set the User Roles for each database that I need to connect to. It is good practice to limit the permissions to those needed by the application. Typically this is read and write, but sometimes you can get away with just read. The less the better.
We have a DB server with a couple web app db's on there (don't get a ton of traffic). We'd like to make use of the server and allow it to be the DB server for sharepoint. I'm assuming it's not good practice and that sharepoint should have it's own exclusive db server. Am I right in that conclusion, or is it alright if we put the database on a server that already hosts other databases.
You can install SharePoint on an existing DB server, sure. Unless your environment is going to be huge, I don't see why you would give it its own DB server. It will use an embedded SQL Server instance if you want, but you'll get better performance if you have the full-blown version. We're running a few SharePoint apps on our DB server with a number of other applications.
The way in which I solve this is to install a second SQL Server instance dedicated to SharePoint, as SharePoint likes to have a lot of control over the database and spews all sorts of stuff such as logins, etc. across the instance, which you really want to separate from your standard line of business instance.
The added bonus is multiple SQL Server instances on the same physical machine are included in your licence.
Be careful with the SQL Server collation. I think SharePoint requires a particular setting for this. See http://www.moss2007.be/blogs/vandest/archive/2007/07/24/sharepoint-2007-and-sql-server-collation-latin1_general_ci_as_ks_ws.aspx for one reference.
Prior to centralizing our environment we had many Sharepoint sites located on servers with existing applications. I'm not a fan of adding an additional named instance as this increases the administrative overhead for the DBA. You have to know how much use you expect of your Sharepoint instance then measure the resource utilization of your existing applications balance it from there.
I have built an application that uses SQL Express 2005 and I want to deploy it, but the problem is that anyone who has SQL Management Studio(or something like that) installed on his computer, can connect to my database and change it.
Is there anyway to prevent end-users from seeing or editing the content of my database, even those with the Administrator privileges?
I guess you're referring to the fact that by default SQL Server installs allow Windows and SQL Server Authentication. If you remove the Windows Authentication mode then users will have to connect via SQL Server authentication.
This from http://support.microsoft.com/kb/247931
SQL Server authentication SQL Server
authentication relies on the internal
user list maintained by the SQL Server
computer. This list does not include
Windows NT users, and is specific to
the SQL Server computer. Users are
created and configured using the SQL
Server Enterprise Manager. To use this
authentication method, perform with
the following steps:
• If you connect
through Open Database Connectivity
(ODBC), in the ODBC Administrator,
choose SQL Server authentication when
you configure the data source.
•In
the ActiveX Data Objects (ADO)
connection string, include the
parameters "UID" and "PWD" when you
use ODBC, and "User ID" and "Password"
when you use the SQLOLEDB provider.
I suppose this is not the answer you hoped for but it is unavoidable that anyone with administrative rights will be able to browse and edit information in the database.
You cannot change this.
Perhaps you could consider WHY you want to prevent this kind of access?
I expect you want to prevent tampering or accidental corruption of the data?
If that is the reason then you can go a long way to prevent corruption by adding constraints to your database. Add foreign key constraints, uniqueness constraints, everything that will help prevent data corruption.
Then an administrator would need to deliberately undo these constraints before they tamper, which would prevent most accidental corruption but of course not prevent malicious vandalism.
If you are concerned about protection of your intellectual property, you could encrypt the programmatic components (stored procedures and views and functions). This kind of encryption is not very strong but prevents casual inspection.
Encryption is added by using the
WITH ENCRYPTION
clause in your CREATE or ALTER statements.