I have an APEX application in which I need users(students) to be able to login and view their own information. I have both the usernames and passwords stored in a table within the database I'm using.
Is there a way of using these credentials to be able to log in individually? and how would I go about doing so?
I'm very new to APEX so sorry if this is an easy question.
Many thanks
Saying that each student has to see only their own data means - I presume (as it is about students) that there are as many database users (schemas) as students in your class.
If that's so, presuming that each of them will use their own Apex developer and its workspace (i.e. they won't share the workspace), I believe that you'll have to create that many Apex developers and assign each developer their own schema.
That should be done connected to the internal workspace, logged in as Apex admin.
However, as you have to create many users at once, that approach might be tedious. Instead, as you already have list of users stored in a table, you could utilize APEX_UTIL.CREATE_USER procedure and let it do the dirty job.
For example, if your table is MY_USERS, then such a script would do the job:
begin
for cur_u in (select username, password from my_users) loop
apex_util.create_user(p_user_name => cur_u.username,
p_web_password => cur_u.password
);
end loop;
end;
For more info, read this: https://docs.oracle.com/database/apex-18.2/AEAPI/CREATE_USER-Procedure.htm#AEAPI114
I would use a the Custom Authentication Scheme. It is documented, so if you need help, just clicked on the "?" buttons next to the various fields.
The example code is obviously not going to work, so please do not copy and paste blindly. Adapt it to your situation and hopefully, you are encrypting/hashing the passwords.
That gets you started with login (authentication). Next, to the second part of your question, that students should only see "their own information" (authorization). There are no clearcut answers to this question as there are many strategies available and many issues to consider. For example, how you design your application and data schema, what database features are available to you, and regulatory compliances that you need to meet.
A great starting point to read about these "database features" can be found here, on Real Application Security and Virtual Private Database.
The alternative includes a "poor man's implenentation of VPD" that Martin D'Souza wrote about a long time back.
HTH!
Related
Let me preface this with the fact that I don't know much about VBA. I have created a database that will be split and the front end will be distributed to 14 different project managers. The database is intended to allow users to enter bi-weekly updates to their projects. I hope to get some guidance on creating usernames and passwords so that PMs can only access their project data.
I don't mind creating and issuing usernames and passwords to each user, but I am trying to avoid creating 14 copies of the database. That would make providing updated databases a nightmare.
Hopefully this isn't too basic of a question for this group.
yes, you can control users access, you need to create a user table in your backend database that will hold their firstname, surname, password, and any other user specific data that you might need, e.g. department, access level, etc.
In your front end, you need a login form and you make that the Display Form for your fe (set in the access options menu). You check the username and password entered matches what is held in your database, and if it's correct, you load the appropriate form, usually a main menu, and show them the appropriate data based on the login they used. You may need to hold the login they used in a TempVar, so you can access it from any form, report, query etc in your frontend.
You will need something like LASsie (Light Application Security) or program a similar solution yourself.
Also, you may enjoy my article Deploy and update a Microsoft Access application with one click.
(If you don't have an account, browse for the link: Read the full article.)
Can someone tell me if there exists SQL code for Derby to change a username or password of a database? How may I reproduce this to prevent it in future in my application?
What I'm busy doing, is to create a custom SQL query builder in my Java desktop application, but I want to prevent an end-user to accidentally or purposefully delete any table or database, change the username or password.
What SQL scripts can be run here which I may cancel out in my coding, and what basic things am I missing here?
All thoughts appreciated.
(This question has been asked on SE/Security to get different views. I want to get as much info on this as possible)
Derby has an entire manual on security topics: http://db.apache.org/derby/docs/10.11/security/
Perhaps you can start by studying that manual, and experimenting with the approaches it suggests, and then ask some more specific questions?
So I wanted to know if there is an acceptable method to Allow SQL Injection.
Example:
Limit permissions on the table(s)/database(s)
Why you ask?
My employer wanted to devise a way to test the skills of applicants, one suggestion was to allow resume submissions via SQL Injection.
Any thoughts? suggestions?
You could use roles. Create a role for the web application (or whatever) that is used to connect to the database. Limit this role to only permit INSERT and access to necessary tables for applying. Applicants with access to your database through the application could then only use SQL injections to add their resume.
It may be possible for someone more talented in SQL to use injections in a way that increases the role's permission. But I think if the role had limited access to only specific tables and didn't have CREATE or GRANT privileges, the user wouldn't be able to create new roles.
Here is some information on roles to get you started:
Adding Roles to MySQL with MySQL Workbench
Creating Roles in PostgreSQL
GRANT command - used to add privileges to users on table, database, etc. This page is for PostgreSQL, but MySQL is very similar (see this SO answer)
Given that the reason behind this is to test people's ability, create a database with data you can afford to lose. Set up a form that posts to a coldfusion or php or java or .net or some other type of page which connects to that database.
On the form, put a textarea and submit button. On the form target page, log what they put in the textarea. Compare the log to the database to see how it turned out.
Then test to your heart's delight.
my question is rather simple.
Can i grant permissions on a database table wise? something in the lines:
User Management has permission to select, update, insert and delete on table Projects
User Supervisor has permission to select, update, insert on table Projects
User Colaborator has permission to select on table Projects
If so, I could set up a system to create database users based on the levels of access of my application, much like the examples above.
Is it a valid mechanism to use this to secure a application?
is it worth on a real world application?
i've used PHP with Oracle and MySQL, but I'm look for a database/language agnostic answer, but any example would be useful.
pushing my luck a bit, what about per record permission granting?
also, what about table schemas, are they a more acceptable then table based permissions?
The main problem with using database security would be that you need separate connections for each user rather than being able to use a "service user" for the connection from your application server to your DB server. That would mean that you would no longer be able to use database connection pooling have to "connect" and "disconnect" from the database for every user request, which is not very efficient as connections are relatively expensive.
Having said that, there is good reason for using separate users in the database, such as DATA_USER (which the application server connects as) and DATA_OWNER (which owns all the tables but is used only for DB maintenance) and then only give DATA_USER the permissions that it needs to, e.g. only select on a lookup table. By separating DATA_USER and DATA_OWNER you can add an additional level of confidence that your application won't issue DDL commands (e.g. dropping a table).
Answer to part 1:
Yes as long as you handle the responses correctly.
Part 2:
It's not as good as implementating security in the application layer, as most applications will need flexibility in the solution (what if you want a user to get increased privledges, have to code in lots of alter/deny/grant scripts)
Part 3: (Speaking from purely MSSQL) Row-level permissions aren't possible. Create custom views for this purpose.
I've got a string containing an SQL statement. I want to find out whether the query will modify data or database structure, or if it will only read data. Is there some way to do this?
More info: In our application we need to let the users enter SQL-queries, mainly as part of the applications report system. These SQL queries should be allowed to read whatever they like from the databse, but they shouldn't be allowed to modify anything. No updates, deletes insert, table drops, constraint removals etc.
As of now I only test whether the first word in the string is "select", but this is too constricting and too insecure.
You should grant only select privileges on your tables for the login used by the application to be sure.
Create a new user for that part of the application that only has select privileges. Bear in mind that you'll also need to create synonyms for all the tables/views that that "read-only" user will be able to view.
The "regular" part of your application will still be able to do other operations (insert, update, delete). Just the reporting will use the read-only user.
As Horacio suggests, it is also a good idea/practice to add "wrapper" views that only expose what you want to expose. Some sort of "public API". This can give you flexibility if you need to change the underlying tables and don't want to/can't change the reports to the new definitions of said tables. This might, however, be seen as a lot of "extra work".
I agree with others that the right thing to do is use a separate schema with limited access & privileges for those queries that should be read-only.
Another option, however, is to set the transaction read-only before executing the statement entered by the user (SET TRANSACTION READ ONLY).
Create VIEWS to expose the data to end users, this is worthy because of three things:
The end user doesn't know how really your database look like.
You may can provide a simpler way to extract some pieces of data.
You can create the view with a read-only constraint:
CREATE VIEW items (name, price, tax)
AS SELECT name, price, tax_rate
FROM item
WITH READ ONLY;
Something that has worked well for me in the past, but may not fit your situation:
Use stored procedures to implement an API for the application. All modifications are done via that API. The procedures exposed to the front end are all complete units of work, and those procedures are responsible for rights enforcement.
The users running the front end application are only allowed to call the API stored procedures and read data.
Since the exposed API does complete units of work that correspond to actions the user could take via the GUI, letting them run the procedures directly doesn't get them any additional ability, nor allow them to corrupt the database accidently.
SELECT * FROM table FOR UPDATE works even with only SELECT privilege, and can still cause a lot of damage. If you want to be safe, the read only transactions are better.