I'd like to securely store an encryption key somewhere in an SQL Server database that is only readable by internal functions and SP's. Is there a way to achieve this without it being visible to any user accessing the database (no matter what the role).
What i'm trying to do:
I need to have a simple sort of "license key" as a new column for my individual users. The plan is to hash their usernames using a client-specific key (which is a concatenation of the above mentioned key and a product key).
A function would be created that:
Takes the product half-key as a parameter
Fetches the secure client half-key in the database
Combines them together into a complete client-specific key
Uses this key to hash the username into a final output
Ultimately what i'm trying to do is give specific database users "licence keys". Since the customer has access to the database, i don't want them to be able to do add licence keys to other users as well. If the above doesn't work, i'm also open to other suggestions to achieve this.
I'm looking for a second opinion from maybe someone with more experience with SQL.
So I have a database that looks like this :
Company has multiple Clients which has multiple Projects which has multiple Tasks, etc.
In my application a user is assigned a company and cannot query information that isn't tied to it. So whenever a user tries to retrieve Client/Project/Task/Punch I need to make sure that my query contains a Where clause that looks like WHERE companyID=[user's company id]. This add a lot of joins when I need to fetch Punch since I need to go up the chain to see if the company is the same as the user.
Since a client/project/task/punch will never switch from a company to another one, I was wondering if there's any red flag to add a companyID field in project/task/punch in order to simplify the querying ?
I'm using PostgreSQL
If I understand correctly, what you are buildng is a multitenant system, where your companies are the tenants. If that is the case then there are no red flags - on the contrary, your main concern is to isolate data belonging to different companies in the most efficient and most secure way.
I find this old blog post to be a basic but clear introduction to multitenancy.
The recommended way to go was then, and is today, the third option: one DB, many schemas. I'm no Postgres expert, but I believe it supports that option quite well.
I would like to know, is there a way to do CRUD operations using non primary key for a cache defined in grid gain using thin client API (Not by using sql query).
Without using SQL, Ignite is basically a key-value store. You could use a ScanQuery, which iterates over every record in the named cache.
But really, the answer is to use SQL.
Azure recently announced that they are discontinuing the EasyTable and EasyAPI aspects of App Services. I've extensively used both of these, and want to continue to do so.
this article explains that all the existing functionality is still there, you just manually have to do it yourself. Now I'm relatively comfortable with creating basic SQL tables myself, but azure easy tables have some special properties that I don't know how to create.
When you creat an Azure Easy Table, it creates an id column which has auto-created values that look like dc405ef6-6c40-465d-ba8a-00e1ad86d5e4 - I know how to make an auto-incrementing id column but not one like that. It also has columns for createdAt and updatedAt, of type datetimeoffset, which get automatically filled in.
What's the CREATE TABLE commands to replicate this?
Also, not sure if there's something special I have to do to make my odata queries not have deleted rows show up.
What's the CREATE TABLE commands to replicate this?
You can set the default value of the column to be NEWID() function and it will insert a GUID as value for that column.
Question: I'm planning the database for one of my programs at the moment.
I intend to use ASP.NET MVC for the user backend, the database being on Linux and/or on Windows.
Now, even if I would only make it for windows, I had to take into account, that different customers use different database systems. Now, I figured I use nHibernate, then I can put everything in the code, and it works on all mayor databases, such as Oracle/Sybase/MS/PostGre/MySQL/Firebird.
My probem now is GUIDs. SQL Server uses GUIDs, while the rest uses integer auto-increment as primary keys. While auto-increment is better in theory, it creates problems keeping multiple databases in sync, or problems manually changing things, which requires CSV import/export...
Now, because of the inherent problems with autoid in practise, I like the GUID system better. And since a guid is a 36-character string, I could use varchar(36) as a primary-key, but a varchar as GUID, might just not be an ideal solution...
How would you solve this problem/what do you use as primary-key ?
Or how do you evade the auto-increment problems, say insert a csv file without changing the autoid...
A Guid key using the guid.comb generator key is usable in any database, even if it doesn't have Guid as a native type.
You could also consider generating a primary key which is a combination of auto-increment (i.e. setting up a sequence) and an unique identifier of the machine it was generated on, maybe using the MAC address.
See this for a discussion.
This way you have a locally unique (thanks to the sequence) ID which is also globally unique (thanks to the MAC address part).
I know, I know, you can spoof a MAC address but it's up to you to decide if this is really a risk in your domain. Also, the ability to spoof it could be handy when you test your code.
Please explain better what happens when a new customer DB is born. Will it be registered on the Server? If yes, you can assign a DB-id on the server, and use it in lieu of the MAC address, just assign a number to each new DB and use it along with the sequence.
Basically, if you want an "unique DB instance ID" to avoid "table id" collisions, you have only two choices:
1) Server assigns the DB ID whenever a new DB is added
2) Client autogenerate a unique ID, and this usually needs using the MAC address, either "raw" or processed somehow.
I honestly can't see alternatives given your current description of your problem.
Oracle and PostgreSQL support GUIDs as well, there is no need so use sequences there (and of course Diego is right: if you use your own algorithm to create GUIDs you can always store use a varchar column with your own generated GUID)
Note that it's spelled PostgreSQL, never PostGre
I have never had any trouble using Guids. We used Guid.Comb in a system with many records (millions) and had no trouble because of the Guids themselves. The selling point for me is that I can generate the Ids before i persist something to the database. Even on the client. Which is very helpful in CQRS scenarios.
The only thing that I think you should also consider is human readability. It's hard to look at the database and match records in a lets say master/detail scenario.
And a note on Firebird... Uuid is written as an octet. And most clients that I've used to manage the database can't represent those in a decent format. So it's usually just displayed as a couple of characters (probably by just decoding a byte array as a string). I don't know about other providers though. SQLServer Management Studio for example shows them just fine.