Admin audit log is written into vx_trx_log table whenever policy/role/user/group is getting created/updated/deleted .We are seeing vx_trx_log table is growing very fast. This also might affect DB performance. We do not have any flag to disable the admin audit.
Related
I have an active admin application where I try to implement role based restrictions on the resources. I have a number of features which are assigned to a role. For example , the feature "create_user" and "assign_task" is assigned to the role "manager". I have a table for storing feature list, a table for storing the role list and a table for storing the features assigned to roles. The manager role is assigned to number of users. When a user logs in, based on the features which are assigned to him, i try to hide some meus. eg: menu if: proc{current_user.can_create_taskr?}, :priority => 6 . The problem I get is whenever I try to refresh the app, the queries are running everytime, which is unlkely. Is there any way to execute these queries only once after the user logs in and use the results elsewhere
Out of the box ActiveAdmin is relatively inefficient in evaluating menu access each time. If you wish you can use Rails low level caching but my advice is don't worry about it until you have to. If the SQL is slow be sure to use indexes.
I have an audit log which works great in my rails application. What is the best approach to make audits of the audit log. How can I track any changes or prevent them? Basically i am worried about the value of the audit logs if someone can tamper with them. I need to be able to audit my audit logs. And then...... audit the audits of my audit logs, so on so forth into infinity.
So far I have tried adding auditing to my audit logs. But then I run into the issue of those audit logs not being audited if they are removed or modified.
I am trying to create an application which will provide IT services for different organizations.
I have a long form for creating a user where I have to search all users within that organization through LDAP. This turns out to be a time consuming process. I can search all users and later put them into a list and use that list in a different situation. But the problem is that at the same time any administrator can modify or delete a user. I have thought of putting the list into an application scoped bean. But I have a different organization as well, which has totally different set of users.
What is the appropriate solution in such a situation?
I would say this is not something that can be handled by the scope if you are running multiple instances of a JSF application that all access a single database.
This should be handled by a lock on the object in the database, i.e. when you load the editing view for a user, the user object is locked for editing to the others (like a boolean column named locked). Saving or canceling editing, releases the lock (or it expires if the user forgets to do any of it).
Application scoped data are visible to all users of your application. That is, if you put some list in application scope, and later reference it in view, it will be the same instance for every user. Also, you should beware of severe concurrency issues imposed by such approach.
Most probably, you scoping problems will end when you'll put your list of users in session scope, where it most naturally fits. You'll load the list of users of a particular organization when a user with appropriate rights demands it in some view.
From this point you'll face the actual problems that you're worried of, and those are problems that arise in a multiuser environment concurrently accessing shared resources (like administrators modifying users in your example). One of the things that you're afraid of, as it can be followed from your question, is the 'last commit wins' strategy, under which edits made in time by another users before the last user committed the edits will be lost, or overwritten, by the last commit.
This type of problems can be solved by introducing some type of 'locking' on the database level. Basically there are two types of locking: optimistic and pessimistic.
What Is proposed in another answer is an example of pessimistic locking, under which no one is allowed to access the data unless database lock is released. The seip is as follows: user who is going to update the data places an exclusive lock preventing other users from manipulating data until the lock is released. The idea behind is that the users will update the database resources synchronously and that possibility must be ruled out no matter how frequent those conflicting updates actually happen.
Another option - optimistic locking assumes that many users can access and modify data simultaneously, without locking the database resources. This is typically achieved by storing record version in the database. When a conflict occurs, a user can be prompted about that, preventing information loss. The idea behind is that though conflicting updates are possible, they will in fact be rare, and in any case the user will be notified of that conflict.
Note that the setup without locking, or 'last commit wins' strategy is basically the same as optimistic locking, when the final user always chooses to overwrite the data.
As you can see, there are some approaches to choose from. So first learn about them yourself, then maybe your not-so-like-question will vanish. And if not - you'll be able to come back and post a new question on concrete topic with concrete problem so that we won't speculate but will concentrate on helping you.
I want to build and maintain a table of users. All users that access the ASP.NET MVC site are authenticated via Windows Authentication so they're bound to have a unique username. I'm grabbing the user name from:
System.Web.HttpContext.Current.User.Identity.Name
I feel like I could go two ways with this.
Anytime the user table or any tables that references the user table are accessed, I could add the user if it doesn't exist. I'm worried this might be very error prone if user's existance isn't checked.
Anytime the user visits any page on the site, check if that user exists in the db and if they don't exist, add the user. This may have a lot of overhead as it'll be checked every page change.
I'd like to hear which of these is the better solution and also how to implement them.
I think a better way would be something similar to the option two.
Anytime a user visits a page, check a session variable to see if that user was checked against the DB. If the session variable is not there, check if that user exists in the DB, add the user to your table if necessary, then set the session variable.
That way you don't have to hit the DB on every request.
I am developing a gallery which allows users to post photos, comments, vote and do many other tasks.
Now I think that it is correct to allow users to unsubscribe and remove all their data if they want to. However it is difficult to allow such a thing because you run the risk to break your application (e.g. what should I do when a comment has many replies? what should I do with pages that have many revisions by different users?).
Photos can be easily removed, but for other data (i.e. comments, revisions...) I thought that there are three possibilities:
assign it to the admin
assign it to a user called "removed-user"
mantain the current associations (i.e. the user ID) and only rename user's data (e.g. assign a new username such as "removed-user-24" and a non-existent e-mail such as "noreply-removed-user-24#mysite.com"
What are the best practices to follow when we allow users to remove their accounts? How do you implement them (particularly in Rails)?
I've typically solved this type of problem by having an active flag on user, and simply setting active to false when the user is deleted. That way I maintain referential integrity throughout the system even if a user is "deleted". In the business layer I always validate a user is active before allowing them to perform operations. I also filter inactive users when retrieving data.
The usual thing to do is instead of deleting them from a database, add a boolean flag field and have it be true for valid users and false for invalid users. You will have to add code to filter on the flag. You should also remove all relevant data from the user that you can. The primary purpose of this flag is to keep the links intact. It is a variant of the renaming the user's data, but the flag will be easier to check.
Ideally in a system you would not want to "hard delete" data. The best way I know of and that we have implemented in past is "soft delete". Maintain a status column in all your data tables which ideally refers to the fact whether the row is active or not. Any row when created is "Active" by default; however as entries are deleted; they are made inactive.
All select queries which display data on screen filter results for only "active records". This way you get following advantages:
1. Data Recovery is possible.
2. You can have a scheduled task on database level, which can take care of hard deletes of once in a way; if really needed. (Like a SQL procedure or something)
3. You can have an admin screen to be able to decide which accounts, entries etc you'd really want to mark for deletion
4. A temperory disabling of account can also be implemented with same solution.
In prod environments where I have worked on, a hard delete is a strict No-No. Infact audits are maintained for deletes also. But if application is really small; it'd be upto user.
I would still suggest a "virtual delete" or a "soft delete" with periodic cleanup on db level; which will be faster efficient and optimized way of cleaning up.
I generally don't like to delete anything and instead opt to mark records as deleted/unpublished using states (with AASM i.e. acts as state machine).
I prefer states and events to just using flags as you can use events to update attributes and send emails etc. in one foul swoop. Then check states to decide what to do later on.
HTH.
I would recommend putting in a delete date field that contains the date/time the user unsubscribed - not only to the user record, but to all information related to that user. The app should check the field prior to displaying anything. You can then run a hard delete for all records 30 days (your choice of time) after the delete date. This will allow the information not to be shown (you will probably need to update the app in a few places), time to allow the user to re-subscribe (accidental or rethinking) and a scheduled process to delete old data. I would remove ALL information about the member and any related comments about the member or their prior published data (photos, etc.)
I am sure it changing lot since update with Data Protection and GDPR, etc.
the reason I found this page as I was looking for advice because of new Apply policy on account deletion requirements extended https://developer.apple.com/news/?id=i71db0mv
We are using Ruby on Rails right now. Your answers seem a little outdated? or not or still useful right now
I was thinking something like that
create a new table “old_user_table” with old user_id , First name, Second name, email, and booking slug.
It will allow keep all users who did previous booking. And deleted their user ID in the app. We need to keep all records for booking for audit purpose in the last 5 years in the app.
the user setup with this app, the user but never booking, then the user will not transfer to “old_user_table” cos the user never booking.
Does it make sense? something like that?