Mike.Sheen wrote:Is there a reason why you want to supply SQL credentials within the connection wizard?
I guess with all the SQL databases I've logged into over the years, it's just weird for me to see a SQL login dialog with no username/password option (unless it's using integrated authentication, which it's not, but that's a different discussion).
Then there's the fact that you can't tell from the connection wizard what username it's trying to use. It's like I'm expected to have read the manual before running the program.
But mostly it's because I don't want to use a default password. That's really bad for security.
I also think it would be better for security if you could choose a different username. Just like you can for JiwaUser/JiwaReports. I realise the credentials would need to be stored somewhere, but I think having an encrypted password in the registry, or in an obscure config file, would be preferable to a well-known password.
I'd put money on there being many customers whose JiwaLogin user has waaaay more privileges on the SQL server than they're supposed to (unless you've got code that's changing it!), which means a well known user with a well known password is a dangerous thing.
This also would provide better security silos for primitive 'multi-tenant' scenarios - here I'm thinking of the potential for a type of hosted environment for really small clients (one or two users) where the cost of a SQL Standard instance can be shared instead of having multiple SQL Express or localdb instances.