We are in the process of migrating from one domain to another and it seems users cannot see the subscriptions they created when they were logged in using the old domain credentials.
How can I, in bulk, make the users new domain credentials able to see the old domain subscriptions.
This was accomplished by running this in SSMS on the ReportServer dB
DECLARE #OldUserID uniqueidentifier
DECLARE #NewUserID uniqueidentifier
SELECT #OldUserID = UserID FROM dbo.Users WHERE UserName = 'old_domain\user'
SELECT #NewUserID = UserID FROM dbo.Users WHERE UserName = 'newdomain\user'
UPDATE dbo.Subscriptions SET OwnerID = #NewUserID WHERE OwnerID = #OldUserID
Related
I am designing a database schema for a multi-tenant project where a single user might have multiple "profiles", one for different tenants. I am using Supabase to provide a Postgres database along with some of their other BaaS features and hoping to use Prisma to help me manage the schema, relations, and migrations.
Supabase provides their own auth service, leveraging their auth.users table (in the auth schema). I want/need my public.profiles table to have a 1-n relation with auth.users so I can link my user to all of their profiles.
Is there a way I can define this in my schema.prisma file? I have tried manually creating a VIEW in the database and then defining a model for it, but when I try to apply my other Prisma schema changes (npx prisma db push or npx prisma db migrate dev) I get an error that the view/model already exists.
When database is initialized, I create the Auth SQL view in the public schema.
CREATE VIEW "Auth" AS SELECT id, email, role, created_at, updated_at, invited_at from auth.users;
Then in my Prisma schema I replicate the model. This seems to be the approach if you are using introspection, but I want Prisma to manage the schema, not the other way around.
generator client {
provider = "prisma-client-js"
}
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
}
// SQL view in public schema of Supabase "auth.users" table
model Auth {
id Int #unique
email String
role String
createdAt DateTime #map("created_at")
updatedAt DateTime #map("updated_at")
invitedAt DateTime #map("invited_at")
profiles Profile[]
}
model Profile {
id Int #id #default(autoincrement())
// This relation should reference the "auth.users" table
user Auth #relation(fields: [uid], references: [id])
uid Int
client Client #relation(fields: [clientId], references: [id])
clientId Int
firstName String
lastName String
}
model Client {
id Int #id #default(autoincrement())
createdAt DateTime #default(now())
updatedAt DateTime #default(now())
name String
type String
preferences Json
profiles Profile[]
}
Essentially, I need to know how I can create a relation to some portion of the schema that Prisma does not control. Can I define a reference-only model? Or a model that should be ignored during push or migrate operations? Can I define an explicit table name in the model relation definition?
There is this issue that talks about adding more support for views, but it's unclear if/when anything will happen. I'm wondering if anyone has a different solution. If this won't work I may just need to look into using something like NextAuth so I can fully manage the auth schema, but I'd prefer not to rebuild an auth system if I can help it.
You could create a public.users table via Prisma and add a Postgres trigger to duplicate the auth.users data to your public schema anytime a user signs up:
/**
* This trigger automatically creates a user entry when a new user signs up via Supabase Auth.
*/
create function public.handle_new_user()
returns trigger as $$
begin
insert into public.users (id, full_name, avatar_url)
values (new.id, new.raw_user_meta_data->>'full_name', new.raw_user_meta_data->>'avatar_url');
return new;
end;
$$ language plpgsql security definer;
create trigger on_auth_user_created
after insert on auth.users
for each row execute procedure public.handle_new_user();
Does that approach work for you?
Ex: I have tables Table_A, Table_B, Table_C
I have created Role(user) called Username
Create User username with password 'pwd'
Without granting select permission to username able to access some of the tables.
The tables (Table_A, Table_B, Table_C) which have created are in public schema, so without granting select permission we can able to access the tables.
Assuming I have a (over simplified, non secure) table that looks like:
CREATE TABLE users (id SERIAL PRIMARY KEY, user VARCHAR(25), _password VARCHAR(25), email VARCHAR(80));
I want to add a additional failsafe on the column _password that prevents it from being returned on a SELECT * FROM users call, is this possible in PostgreSQL and if so, how?
I tried some versions of https://stackoverflow.com/a/7250991/929999, but this probably isn't what I was looking for. But that got me thinking that there might be a constraint that could be created. I can't find anyone who's tried this or asked it before, so I'm kind of lost seeing as I'm not a database expert by any means.
So for now I dump all results from the database into a custom dictionary placeholder in Python with a function called .safe_dump() that removes any keys starting with _<key>.
And I guess I could create a separate table containing a list of sensitive keys and match those on every SELECT statement via a JOIN or similar, but that would just move the risk of accidentally retrieving a sensitive key from the SELECT call to keeping that "JOIN table" updated.
Is there a flag in PostgreSQL that can filter out of block calls trying to access a key while still allowing it to be used on WHERE x=y clauses?
You can deny permission for that column:
CREATE TABLE users (
id SERIAL PRIMARY KEY,
"user" VARCHAR(25),
_password VARCHAR(25),
email VARCHAR(80)
);
REVOKE ALL ON users FROM laurenz;
GRANT SELECT (id, "user", email) ON users TO public;
test=> SELECT * FROM users;
ERROR: permission denied for relation users
test=> SELECT id, "user", email FROM users;
id | user | email
----+------+-------
(0 rows)
If you'd rather want exclude the column from the output, use a view:
CREATE VIEW users_v AS SELECT id, "user", email FROM users;
GRANT SELECT ON users_v TO PUBLIC;
I am trying to get schema name in sybase database.
First I have create login(user1) from sa user and than i have connect with user1 by giving login name(user1) and password now i have tried to create table by giving following command:-
create table user1.table1(
emp_id int not null,
name varchar(80) not null
)
but it was showing access denied error than i have logged-in from sa user and grant sa_role to user1 and then again i have run above mention query for create table and table were created successfully.
here I am not exactly getting that user1 is schema name or not or how can I identified schema name?
I want to also know that is there any role except sa_role for grant create insert delete table ,views and all other objects of sybase database.
Sybase ASE does not use the schema concept that SQL Server and Oracle use. Objects are located inside a database, and owned by a user - no other logical separations are there. So your syntax is wrong.
create table table1
(
emp_id int not null,
name varchar(80) not null
)
Sybase ASE Create Table
Additionally, Sybase/SAP best practices tells us all database objects should be created/owned by dbo with permissions granted to groups/roles/users to access those objects. Users who own database objects can not be removed, so if User1 gets fired, you will have to identify all the objects he owns, and change the ownership of those objects before his account can be deleted.
So for your example, the dbo user (typically sa) would create the objects, then GRANT permissions (INSERT/UPDATE/DELETE/etc) to the groups/roles/users who need access.
More information on managing user permissions can be found in the Sybase ASE System Administrators Guide Vol 1.
And more information about Roles/Groups from the System Admin Guide.
i'm developing a simple windows application (C#, WinForms, ADO. NET). Application should have a following functionality:
create a login and corresponding user in my database (database1);
add roles to new user (role names: rol1, rol2).
New login can (1) and (2) and so on.
How should I do it ?
What I want:
script for creating an initial user which can do (1) and (2).
script for creating new login+new user+add new roles.
Here's a basic script for adding a new login, user and role:
-- Create login
if not exists (select * from sys.syslogins where name = N'TheLogin')
CREATE LOGIN TheLogin WITH PASSWORD=N'ThePassword',
DEFAULT_DATABASE=TheDatabase, CHECK_EXPIRATION=OFF, CHECK_POLICY=ON
-- Create user
use TheDatabase
if not exists (select * from sys.sysusers where name = N'TheLogin')
CREATE USER TheLogin FOR LOGIN TheLogin
IF DATABASE_PRINCIPAL_ID('TheRole') IS NULL
create role rol1
exec sp_addrolemember 'TheRole', 'TheLogin'
-- Grant rights
grant select on TheView to TheRole
A login is server-wide, and controls if you can log into the server. A user is database specific, and controls what rights you have in a database.