I followed the below article to create dynamic JDBC connection.
How to support dynamic JDBC credentials
I was able to do it properly and when a user try to login a JDBC connection created successfully with their credentials.
But I also want these connections to terminate while the users logout. I am doing session.invalidate() during logout but its not terminating the database connections.
The dynamic connections are retained even after the application is undeployed. They get removed only if I stop the web-logic server.
The timeouts set for the application module are not applied to these connections. Please help me if there is a way to close these dynamic JDBC connection during logout.
I am using JDeveloper 12.2.1
In ADF, you do not manage the db connection directly. The Application Module manages the connection to be used by referring to a DB Connection pool JNDI name that is provided by the Application Server.
Since it is expensive to create a db conn, the App server, WebLogic for example, maintains a set of db connections in a DB conn pool. When an ADF App Module needs a connection it is given one from this pool. When the user ends the (ADF) session, the connection is returned to the pool to be (re)used by another session. You might wish to start here with the docs which explains this. WLS docs will describe how to manage the db conn pool.
Bottom line is you should not be opening/closing db connections programmatically from within an ADF App.
Related
We have a three tier application where the UI connects to a service and the service then uses a standard account to connect to the SQL Server using integrated authentication. On a busy system, it would be helpful to know the application user on whose behalf the service account is making a connection to the SQL Server. Is there a standard mechanism for doing so ? I am thinking of (mis)using the SqlConnection properties ApplicationName or WorkstationID for this purpose. The service layer would set these properties to the application user on the SqlConnection and the sp_who2 output would then display the user information. Thus if 'UserX' logged into the application and Service account 'ServiceUser' connected to the SQL Server, 'UserX' would show under ProgramName and 'ServiceUser' under Login. Would this have a negative impact on connection pooling ? Are there any disadvantages of using approach ?
Would this have a negative impact on connection pooling ?
Yes. The connection pool is partitioned by connection string, so you would have a connection pool per user. But if you limit the connection pools size, the impact may not be material.
Alternatively you can call sp_set_session_context after connecting to add data to the session identifying the end user.
I'm new to SQL Server. I was a postgres user before. I installed the default SQL Server on my local machine and I'm trying to get an old react with node js application of mine working with a SQL Server. When ever my frontend makes more than 1 call to the backend, if my SQL Server has admin privileges it throws
Error: 17810: Could not connect because the maximum number of '1' dedicated administrator connections already exists.
If not, it throws:
Error 18451: Only administrators may connect at this time.
I checked my database configs and it's set to MULTI_USERS, so I don't understand why I can't login without admin privileges. Can someone help me with this? I wasn't able to find anything online.
My NodeJS backend is using TypeORM to connect to the database
The dedicated administrator connection is a different kind of connection. It's not just "a connection being made by someone with administrative access". You would use the DAC when the SQL instance is having some kind problem, and you can't connect at all because resources are all tied up. SQL will reserve some resources especially for the DAC connection to make sure you can still connect.
A DAC connection can be made by specifying ADMIN: as part of your connection string, which will connect to the assigned DAC port.
You shouldn't use this for "routine" admin work. Just connect using a login with the required administrative server roles (eg, sysadmin). You definitely shouldn't use this as part of a regular application's connection string. You shouldn't be using a SQL Server sysadmin login either. Create a user with the appropriate permissions for your application, and don't use the admin connection.
Regarding your second issue: Make sure the instance wasn't set to start in single user or minimum configuration mode using startup flags. Note that this is for the whole instance, it's not the same as the configuration for an individual database.
I have purchased an SSL certificate and installed it using IIS on my remote system. So I can therefore access my remote system using https://myremotesite.co.uk. All is fine, it seems to work; users can register and login to my remote site and download my GUI to run my application which stores and retrieves data from my SQL Server database.
When a user runs my GUI to access my application it prompts them for their login-id and password and, if they are authenticated, my application pops up on their screen. All is well, it all seems to work fine.
However, I have read that access to the SQL Server database itself can be restricted with an SSL certificate and to do this I would need "Encrypt=yes" in the connection string which my GUI uses to check authentication.
Is it necessary for me to do this? Or is safe to just rely on the IIS HTTPS service? So my question is ... do I need to register my SSL certificate with BOTH IIS AND SQL Server or just ONE of them, and if so, which ONE?
Thanks for the answers thus far .. to explain further, the GUI connects to an IIS controlled website which has specific handlers written to perform a restricted set of database queries. So my database DOES reside on my server, but it only allows my server's (local) IIS to 'login' and insert, update and extract data.
Once the IIS website service has extracted data, it then returns the same to the GUI. So the GUI has no DIRECT access to the database. What I am concerned about is if - by some malicious means - the database was copied in its entirety ... could/should I use my SSL certificate to encrypt sensitive data in this event?
I'm trying to figure out which credentials I should be storing to enable use of Reporting Services' Data-Driven Subscriptions. Nothing I type in seems to work. It's all happening on localhost under XP-Pro SP3.
A little background:
I'm able to connect to the localhost server as a Database Engine in SQL Server Management Studio, using either Windows Authentication or the username 'sa' and a given password. However, trying to connect to localhost as a Reporting Services server using those same credentials fails with this error:
Cannot connect to localhost.
Additional information:
Unable to connect to the remote server (Microsoft.SqlServer.Management.UI.RSClient)
No connection could be made because the target machine actively refused it [IP]:80
In Reporting Services Configuration Manager, Windows Service Identity is set up like this:
Service Name: ReportServer
Service Account: LocalSystem
Built-in Account: Local System
Web Service Identity is set up like this:
ASP .NET Service Account: [Machine]\ASPNET
Database Connection:
Server Name: [Machine]
Database Name: ReportServer
Database Version: C.0.8.54
Server Mode: Native
Credentials Type: Service Credentials
The Service Status page is green and running.
The Report Server webpage is available and accessible; I can view and generate reports manually. However, I want to create a Data-Driven Subscription so that I can create multiple reports in one go. This is where I'm running into problems. When I click "Subscriptions", it refuses to let me set one up because
Data-driven subscriptions cannot be created because the credentials used to run the report are not stored, the report is using user-defined parameters values, or if a linked report, the link is no longer valid.
Fair enough, I haven't stored credentials. So I went to the "Properties" section and clicked "Data Sources". By default, the report uses "A shared data source". Switching to "A custom data source" requires me to select credential types. Nothing I enter into this seems to produce a result that will allow me to get past the "Data-driven subscriptions cannot be created..." message and create the subscription.
Anyone know how I can fix this?
That error with subscriptions implies that at least one of the data sources you're using (either for your report or for the subscription data) doesn't have stored credentials.
For example, normally I might be using Windows Integrated Security to connect to a data source, but if I want to store the credentials, I will enter MyDomain\SomeAccount and its Windows password in the box on the Data Source screen, and tick the checkbox to indicate it's Windows security.
If this is done for all the data sources, then you should be able to create a subscription. You don't need to use a custom data source if you're happy to store credentials in the shared data source.
I think you need to store credentials for the data source as well as for the execution account in the SSRS Configuration tool, especially if you're using Local System. Rob is correct about how to set the credentials for the data source, just modify the shared data source directly.
How can I secure connection or db credentials when directly accessing the DB server over the internet from the client side application.
Use SSL, or encrypt the user/password yourself before sending it.
SSL or some other credential obfuscation (depends on database server) will work in the case where you have a remote client directly talking to the server, but that will require the remote side know the credentials. If you want to prevent them from knowing the DB login information you'll have to write some form of adapter.
This question could use a lot more detail.