SQL Server connection configuration heavily broken

kzumbusch

Hi guys,

I'm just evaluating the latest version of SmartAssembly to check for fixes of some minor issues we are having with SmartAssembly 6.8. As we are already storing the name mapping of our release builds in a SQL Server database I'd expect SmartAssembly 6.11 to work right away on our build server.

But after installing SmartAssembly 6.11.1 on my development workstation my mind was completely blown: SmartAssembly just asks for the SQL Server hostname and instance name to configure the database access. What about login credentials, database name, etc.? Do you really expect every user of SmartAssembly to have sysadmin privileges to a database server to automatically create the database with his current Windows login? I'm the main SQL Server administrator in our company and even I have to login with my administrative account to manage our SQL Servers.

Applications like SmartAssembly that run unattended on our automated build servers (not Domain joined) get a SQL Server login with a randomly generated password and get read/write access to their manually created database which might not be the default database name expected by the application. If it's really necessary the user is granted db_owner for this database to setup the database structure but that's it. For the SmartAssembly installation on my development workstation I'd definitely use a separate database to not mess up our production build mappings and result logs. This database would be hosted on the same database servers and would need a separate database name. Unfortunately SmartAssembly 6.11 does not provide any UI support to configure all database settings.

Please change the UI to configure the database access to something useable.

Kind regards,

Kay Zumbusch

Russell D

Hi @kzumbusch, I understand what you're complaining about, however I'd just like to point out that in the context of 6.11 these aren't quite valid - that is it's not the 6.11 release that has caused this problem, it's just highlighted it.

If you've been using a SQL server in previous versions, you've never been able to specify the connection details through the UI, which I agree is poor and it's something we'll look into.

I guess I'm just after some clarification from you about what it is you think has changed between 6.8 and 6.11 (other than us changing the default database type)?

kzumbusch

Changing the default database type is okay and understandable. And the update should work well for our release build server and other installations that are already set up to use a SQL Server database.

But on my development workstation I'm not able to use 6.11 out of the box which was possible with 6.8. With 6.11 I need access to a SQL Server with my Windows credentials to setup Smart Assembly using the UI. As the newer versions of Visual Studio (>= 2012) no longer provide a SQL Server Express instance but use localdb instead there is no way to setup Smart Assembly locally without additional effort. Accessing a remote SQL Server with SQL Server login credentials is also not possible. My regular user account has no access to any SQL Server in our network. I have a separate administrative account as I am the main SQL Server administrator in our company. Automatically using an account with this range of permissions is neither allowed in our company nor advisable from a security point of view. If any application requires sysadmin privileges for a database server it is off the market for us.

I'm working in a rather small company where employees fill out multiple roles. I'm a full time developer and the main database admin for the SQL Servers of our development team. But please consider scenarios where the developer has to ask a database administrator to provide a database for an application. The database administrator will probably select a database name like "zumbuschk-smartassembly" to allow multiple databases for the same application. In this case I would not be able to configure Smart Assembly from the UI.

I've been a database administrator for Microsoft SQL Server and Oracle database servers for quite some time and applications or setups requiring sysadmin privileges on a database server are the worst nightmare you can encounter. I've even seen setups that explicitly ask for the password of the database user "sa" as the username was hard coded in the setup or automatically create new database users without any hints. That is why I react quite allergic to applications that require huge security violations in database setups. Requiring sysadmin privileges and automatically creating databases with a default name are two things I will never accept in any application.

Kind regards

Kay Zumbusch

Russell D

Hi Kay,

Thanks for your thoughts on this, I've forwarded them onto the relevant people to see what we can do about this.