I have a database where I need to deny a user from using the set command. I have done tons of research with no positive results. I am familiar with setting roles or even using grant, revoke, or deny to a user.
My goal here is restrict my user from being able to set items like connection based variables or things like context_info.
You cannot stop a user from using SET. I would COMPLETELY stay away from using anything such as context_info for the reasons you've already figured out, anything can happen to it.
I would also be wary of keeping session specific data or metadata anywhere in the database as it's going to be a security issue as well as a data accuracy issue.
Related
Is there a way to update the Liferay's site page's friendly name through a SQL script?
We generally do this in the control panel through admin user.
While #steven35's answer might do the job, you're hitting a pet peeve of mine. On a different level, you're doing it right if you're doing it on the Control Panel, or through the API and you should not think about a way to ever write to Liferay's database. It might work for the moment, but it might also fail in unforeseen ways - sometimes long after your update.
There have been enough samples for this to happen. If you're changing data while Liferay is running, the cache will not be updated. In case these values are also indexed in the search index, they won't be updated there and random later uses might not find the correct page without you reindexing everything. The same value might be stored somewhere else - or translated. Numerous conditions can fail - and there's always one condition more than you expect and cater for. That one condition might break your neck.
Granted, the friendly name of a page might not fall into the most complex of these cases, but just don't get into the habit of writing to Liferay's database. Or, if you do, don't complain about future upgrades failing or requiring extra work, because the database contains values that the API didn't expect. The problem is that during the next upgrade (if you do it in - say - one year) you'll long have forgotten that you manually changed data in the database and blame Liferay for problems during your upgrade.
Changing data is exactly what the UI and the API are for.
Friendly urls are stored in LayoutFriendlyURL.friendlyURL in your Liferay database so the following query should work
UPDATE "yourdatabase"."LayoutFriendlyURL" SET "friendlyURL"="/newurl" WHERE "layoutFriendlyURLId"=12345;
You will also need to update the Layout table accordingly to match the new friendly url.
I am new to this so forgive me for not understanding the lingo.
I have been using rackspace cloud control panel to build multiple virtual servers, i use them for maybe a couple of hours then i delete them. I need these servers to all have specific and unique names such as: "server1, server2, server3, etc." I also need them to have a specific password unlike the randomly generated password that is assigned by default.
I have been creating each individual server manually (based on an image that's set up) then I have to go back and reset the password andreboot all of them. Doing each one manually is a bit time consuming and I'm sure there is an easier way. Please help me figure this out.
I've been doing some searching but I haven't found anything too relevant to my problem on top of that I'm not too familiar with programming and such.
Basically what I'm looking to do is automatically create these servers with their appropriate names and passwords already built in from the start. I'm not sure if some sort of "API" is the answer, or if there's some sort of script that can be written, or both.
Any assistance is much appreciated.
thanks,
Chris
I have just started using RavenDB on a personal project and so far inserting, updating and querying have all been very easy to implement. However, I have come across a situation where I need a GetOrCreate method and I'm wondering what the best way to achieve this is.
Specifically I am integrating with OpenID and once authentication has taken place the user is redirected to my site. At this point I'd either like to retrieve their user record from Raven (by querying on the ClaimsIdentifier property) or create a new record. The user's ID is currently being set by Raven.
Obviously I can write this in two statements but without some sort of transaction around the select and the create I could potentially end up with two user records in the database with the same claims identifier.
Is there anyway to achieve this kind of functionality? Possibly even more importantly is do you think I'm going down the wrong path. I'm assuming even if I could create a transaction it would make scaling out to multiple servers difficult and in anycase could add a performance bottle-neck.
Would a better approach be to have the Query and Create operations as separate statements and check for duplicates when the user is retrieved and merge at that point. Or do something similar but on a scheduled task?
I can't help but feel I'm missing something obvious here so any advice on this problem would be greatly appreciated.
Note: while scaling out to multiple servers may seem unnessecary for a personal project, I'm using it as an evaluation of Raven before using it in work.
Dan, although RavenDB has support for transactions, I wouldn't go that way in your case. Instead, you could just use the users ClaimsIdentifier as the user documents id, because they are granted to be unique.
Alternatively, you can also stay with user ids being generated by Raven (HiLo btw) and use the new UniqueConstraintsBundle, which lets you attribute certain properties to be unique. Internally it will create an additional document that has the value of your unique property as its id.
I'm a fan of Trac, and of course when I'm just using it for my own, lone, projects I can just give myself full admin rights.
When there are other developers involved, or a not-very-technical manager (or, for that matter someone that is a designer rather than hard-code developer), that needs to be able to keep up with what is happening - and do things like add/update tickets, but not potentially break anything, then the fine-grained nature of the permissions gets to be a little more complicated as to what is required for someone.
What permissions do you use for those groups of people (and other similar ones)?
I generally avoid giving the *_ADMIN perms to users if I can avoid it. Trac 0.11 makes that a little easier by adding TICKET_EDIT_DESCRIPTION.
Depending on the setup and the culture, I'll grant the *_VIEW permissions to authenticated (everyone who has logged in) or in lax setups, anonymous (everyone, even not logged in).
I will generally create a developer group, grant the various permissions to that group. Then you just add people to the group (or add the group as a permission to the user, same thing). Do the same for designer, manager, tester, etc.
A manager would want the various ROADMAP_* and MILESTONE_* permissions. I'd be cautious about REPORT_ADMIN unless the manager actually knows SQL. My boss is generally happy to give me an example spreadsheet of the report he wants and I'll whip up a report for him. Be sure to point out to them that if they setup a custom query that does what they want, they can bookmark it -- everything is in the URL -- so they can go back to exactly that same query with current data using that bookmark.
You'd probably want to let authenticated file and append to tickets--doesn't usually who notices a bug, you still want to know about it. If you lock down the workflow permissions enough, you may be able to give out TICKET_MODIFY to more people as well, though that route will be a bit more work.
Those you have some trust in can probably be granted TICKET_EDIT_DESCRIPTION so they can fix up their bug report formatting when they forgot to to start with.
If you have a lead developer, that individual user should probably have TICKET_ADMIN to deal with adding versions and such.
I typically turn on all the VIEWs, plus WIKI_CREATE, WIKI_MODIFY, TICKET_CREATE (or TICKET_CREATE_SIMPLE if using the Simple Ticket plugin) and TICKET_APPEND.
For users I trust to have a little more power, I'll also turn on TICKET_MODIFY.
For a non-technical manager, I'll also turn on MILESTONE_ADMIN. For a technical manager, I'm likely to jump to TRAC_ADMIN -- but if that's too far, at least add REPORT_ADMIN.
Typically, I'll go ahead and give the developers TRAC_ADMIN... but if you don't trust them that far, the above permissions through the power user level plus TICKET_ADMIN are probably sufficient.
Does anyone know of some good resources related to setting up heirarchical user account systems? I'm currently setting one up and am struggling with some of the more complex logic (especially with determining permissions). I was hoping I might be able to find some resources to help me along.
Some Background:
I'm building a user account system for a web CMS that allows for a nested group hierarchy. Each group can be allowed/denied access to read, write, add, and delete (either explicitly for that group, or implicitly by one of its parents). As if that weren't complicated enough, the system also allows for users to be members of multiple groups. -- This is where I'm stuck. I've got everything set up, but I'm struggling with the actual logic for determining pemissions for a given user.
The manual for CakePHP has an excellent description of how Access Control Lists work.
http://book.cakephp.org/2.0/en/core-libraries/components/access-control-lists.html
Represent the permissions set for a given group as a bit mask. OR-ing the bit masks together will give you the resultant permission set.
Update for #Alex:
I wrote this answer 3 years ago, but I believe I was alluding to the following...
From the question
a nested group hierarchy. Each group can be allowed/denied access to
read, write, add, and delete (either explicitly for that group, or
implicitly by one of its parents). As if that weren't complicated
enough, the system also allows for users to be members of multiple
groups. -- This is where I'm stuck. I've got everything set up, but
I'm struggling with the actual logic for determining pemissions for a
given user.
Assign a bitmask matching the total permission set of a group (or role) in the system:
e.g. 00 (using two bits keeps it simple here!)
The first bit confers Permission A and the second Permission B.
Now say Group A confers the following permission set: 01.
... and say Group B confers the following permission set: 10.
To get the resultant permission set for a user in an arbitrary set of groups you could perform a logical OR on the permission set bit masks:
Permission set for Group A 01
Permission set for Group B 10 OR
----
Resultant permission set 11 (i.e. both permission A and B are conferred)
I do not know the details of the questioner's system, but the system outlined here could be augmented to achieve different group-composition behaviors using different logical operators.
Look at the permissions in the Andrew File System. It allows users to create and administer groups of their own, while selectively assigning admin rights and ACLs. You might find that many of the pesky details are already worked out for you in their model.
Edit: here's a better link to AFS documentation:
http://www.cs.cmu.edu/~help/afs/index.html
Here's the section on groups:
http://www.cs.cmu.edu/~help/afs/afs_groups.html
I've done exactly this before and its no trivial implementation. You're going to want to look at the SecurityPermission class.
[http://msdn.microsoft.com/en-us/library/system.security.permissions.securitypermission.aspx][1]
I have done this before by utilizing XML (which I'm not sure I'd do again) and storing that XML as permission list inside of SQL server in an XML column through a CLR stored proc. The XML would have an element called a "permission" and then the permission would actually be a ENUM inside of the code. Each permission was a new implementation of the SecurityPermission class (linked above) Users were tied to groups which were defined in SQL server and then as the user was added/removed to groups, the XML doc would get updated to reflect which groups they were apart of.
As soon as the user logged in, the users credentials would be loaded into the application store (session) and then would be accessed accordingly. When authorization needed to take place the XMl in the application store would be pulled down loaded into the SecurityPermission via the "FromXML" method. At that point I would use the following methods to determine if the user had permission:
Demand
Intersect
Union
IsUnrestricted
IsSubSetOf
etc., etc, etc.
At that point after performing the Demand I was able to determine if the caller had access according to how I implemented my security routines in the SecurityPermissions.
Again, this is leaving out a TON of detail, but this should get you going down the right path.
Take a look at this name space as well: [2]: http://msdn.microsoft.com/en-us/library/system.security.permissions.aspx "System.Security.Permissions"