Supabase url and anon tokens are very easy to retrieve from any site using them. This is normally not an issue for interior tables because you can set up RLS to restrict user from viewing/modifying/deleting data on those tables. But I cannot find anywhere that I can lock down the supabase.auth.signUp() function to a specific domain. I need this to restrict someone from stealing my credentials, building a separate site and flooding my users by signing up random users. I have figured out how to restrict sign ups all together but that is not what I am looking for unless I am missing something with moving this functionality to the server and use the service key instead.
What is the best way to restrict signups to my supabse instance to only users on my domain or those that I deem exceptable?
I found a solution with a trigger.
You need to create a new function:
CREATE FUNCTION
public.check_user_domain()
RETURNS TRIGGER AS
$$
BEGIN
IF NEW.email NOT LIKE '%#test.com' THEN
raise exception 'INCORRECT_DOMAIN';
END IF;
RETURN NEW;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;
Create trigger:
CREATE TRIGGER
check_user_domain_trigger
before INSERT ON auth.users
FOR EACH ROW
EXECUTE PROCEDURE
public.check_user_domain();
I tested it on my application and it works.
I recorded a short video on Youtube:
https://youtu.be/C-HoRO7Wrhg
Hope it can be helpful for you.
Related
How to create a column in parse.com such that I can associate each row with a particular user? Also how to protect each row with the user so that others can not perform data modification on that particular row?
For most purposes, you want a Pointer column to the user.
For securing your data to that particular user, you'll want to look at object-level access control. You should be able to find most of what you need in the guide: https://parse.com/docs/ios/guide#security-object-level-access-control
(There are also similar guides for JS and Android)
Per this link: https://parse.com/questions/data-unique-to-user on the parse site, add a column that is a User to the table you want associate. Then use Parse.user.currentUser() to set that value.
The scenario : an Oracle 11g database containing some sensitive user data that could result legal liabilities if disclosed to the wrong party.
The desired effect : only a certain user, connecting from a certain IP, can see the column that contains this sensitive user data
I am not sure that hidden columns or virtual columns are the right ways to do this. It seems that Fine-Grained Access Control could help. I am not sure of what is the best solution. The restriction by IP is probably done at the listener level?
The question :
How can we restrict the visibility of a column so it is only available only to a specific user? All the other users would never see the column, not even when doing a "DESC TABLE_WITH_SENSITIVE_DATA"
Thanks for any tips.
Simplest way to do this is to create a view on the table that does not contain all of the columns. Don't grant select on the table, but only on the view.
The "proper" way to do this is with Fine-Grained Access Control (Virtual Private Database), which can replace the contents of columns with a NULL if certain conditions are not met.
See the example here: http://docs.oracle.com/cd/B28359_01/network.111/b28531/vpd.htm#autoId17
You can probably build this sort of functionality yourself if you're feeling both impoverished and skilled.
Do you the ability to modify roles and create views? Perhaps you could create two separate views and grant access to two different roles for that table. All users that are restricted from seeing the sensitive data would belong to a "restricted" role and the others would have access to the "unrestricted" role. You would need to grant privileges on each view to the appropriate role.
It is important to note that there are restrictions on updating the underlying data associated with a view. As explained here, views that contain set operators, aggregates and GROUP BY DISTINCT and joins and not modifiable.
I have a form that contains several data blocks, all the fields are bind to the database by setting their properties to the database column name. All the items on each block are displayed on one canvas.
The items on the form contain personal data, however information like the customers phone numbers and addresses are stored on separate tables on a one to many mapping and is linked by the customer number, it takes into consideration the customer can have many phone numbers and many addresses.
The biggest problem here is when the user user is in query mode and has entered information on each block when they try to leave a block they get a message asking them 'Do You Want To Save Changes'. This happens for each block. So this message comes up several times.
What i am trying to achieve is this message should be suppressed so the user is asked this only once. I know once the user answers yes i can do_commit on each block to make changes save. However i have no control over this message and i would like to know the best way to structure an application to avoid this.
Add to trigger where you execute_query or do commit something like this.
:SYSTEM.MESSAGE_LEVEL := '25';
COMMIT;
:SYSTEM.MESSAGE_LEVEL := '0';
This suppress system messages. You did not write what trigger do you use in leaving block.
this may be a easy question, but I really need a light to go on.
I have this huge PHP system in codeigniter, and I'm using the library Quick Auth, and I need let users log on only at one computer/browser at a given time. So if Jake logs on In PC1, then Jakes tries to log on in PC2, PC1 session get invalidated and closed.
I was trying to manually search in the ci_sessions database table to try to eliminate the other user session, but seems like too pain. I want to know if there's one simple solution, I have no problem extending session, but I need more like an advice.
Thanks in advance
You will have to modify either the table indexes or session library code to limit one user to a single session. This can be done by:
Adding a unique index for the username (or ID) and the cookie/session ID
Modifying the library code to INSERT OR REPLACE based on the user/cookie
Like the title says, I've been asked to come up with an estimate for retrofitting an existing asp application.
The current security mechanism controls access to different parts of the application (page-level restrictions), but has no mechanism for flagging individual records as restricted. Assigning rights to a user (using the existing, custom access management code) is no problem, but enforcing the rights is a different matter - each asp page has embedded sql - there's no use of stored procs, objects, etc.
Is the only solution to modify each table and query, or is there a better way? Any pointers, suggestions or prayers would be welcome.
This is classic asp, running on IIS6, against an oracle database.
Update: Here's a user scenario.
We have users, managers, directors, and VPs. The managers can see data created by users who report to them, but not users who report to other managers. Users can't see data created by any managers. Same thing with directors - they can see down, but their reports can't see up.
This sounds like an ideal time to implement row-level security. Oracle has a package DBMS_RLS that allows you to define arbitrary access policies that can be applied to one or more tables that limit what rows a particular user is allowed to see. Conceptually, when a user issues a query with no filters on a protected table, i.e.
SELECT *
FROM my_table
Oracle automatically and transparently inserts a WHERE clause defined by your security policy that limits the result set. You shouldn't need to make any changes to the SQL your application is executing.
Assuming you need maximum granularity, the ability to "grant" each and any row to any of very many users, then you have a many-to-many relation, yes?
So apply the following pattern:
Add a tables of users.
Then, for each restricted table, so the following:
Rename it tablename + "_base".
create a many-to-many table that
associates that table's id with a
user id, called tablename +
"allowed_user".
create a view with the name table
name that joins tablename_base to
table_name_allowed_user, with a
select* from tablename_base and
user_id from tablename_allowed_user.
This view should meet Oracle's
requirements rto be "inherently
updatable."
Now comes the hard part. You need to add "and user_id = $user_id" to every query. Find the various functions you're using to make queries. Wrap those function(s) in ones that gets the user id from the session and add that predicate.
One passable way to do this is to read select string, find the all "where"s (for subqueries there may be more that one), and replace it with "where (user = $user) and ". For queries that don't have a where, you'll need to insert this before any "group by" or "order by". This is fragile, so obviously you'll test that this works for all pages (you have an automated test for all pages, right?), and add hacks to cover special cases.
"update" statements won't have to change; "inserts" will presumably insert both to the view and then do a separate insert to the table's "allow_user" table with the id of the inserting user, to automatically grant teh inserting user acces to what he inserted.
If your number of users is more limited, or you're restricting types of users, you can go with a strategy of multiple views named for the user or type; then you'd replace tables names in the queries with the appropriate views.