Restrict access by time with spring security in grails application - authentication

I'm looking for the way to restrict users access by time in my grails application. I mean that users will be able to use (not only login) application only in allowed timeframes defined by days of week and start & end hours.
Could anyone advise the best way of doing this?
I'm thinking about adding some set of tables to my domain model which will contain time access rules. This rules will be applied to roles and users. Users rules will override roles rules.
As I understand, I need to implement some Authorization (not Authentication) Filter, which will do the check of time restrictions.
Am I one the right way? If so, then could anyone provide some usefull links for this task?

Aha, I already answered this on the mailinglist.
What I wrote:
Possible solution (two-fold):
For login:
Custom UserDetails class that throws appropiate exception if outside
timeslot (not sure if it is the most semantically correct place to do
it, but it's easy there).
For people already logged in:
Quartz job that run at the boundaries (like 2pm if thats when a slot
ends) that run through active sessions and invalidate them.
You can keep a list of active sessions in various ways, one (one and a
half really, not sure if you can use Burt's plugin in a programmatic
way) are covered here:
In grails, how do I get a reference to all current sessions?
I see now that the AccessDecisionVoter is a better solution than the custom userdetails, but the answer still remains for the same for the already logged in people.

Related

Alfresco permissions depending on whether document is currently part of workflow or not

Out-of-the-box, an Alfresco user can read a document based on:
The document's permissions
The user's role
The user's groups
Whether the user owns the document or not
Maybe some other factors I forgot?
Now, I want to add a new factor: Whether the document is currently part of a workflow.
Alfresco's permissionDefinitions.xml allows me to define permissions based on authorities such as ROLE_LOCK_OWNER etc, but it does not seem to be the right place to add permission conditions.
I guess I will have to write some Java source code, but I am not sure what classes are responsible for this, and whether there is an Alfresco way to customize them?
So, I assume you want to somehow have nodes that are attached to a workflow have different access rights? You need to think about the behavior you want in all of the UIs and protocols you are exposing (e.g. share, WebDAV, CIFS, FTP, etc.).
If you want to set a permission on a node, you can do that via JavaScript as well as Java (See http://docs.alfresco.com/5.2/references/API-JS-setPermission.html and http://docs.alfresco.com/5.2/references/dev-services-permission.html). As was mentioned in one of the comments, you can also get the number of active workflows on a node by referencing the activeWorkflows property in JavaScript (http://docs.alfresco.com/5.2/references/API-JS-ScriptNode.html) or in Java
Depending on the specifics, I might implement this in different ways, but if all you want to do is have the permission change, you could just update it at the beginning and end of your workflow with a simple javascript call. The only thing bad about that is that it doesn't take into consideration the workflow getting canceled. You could also create a policy/behavior on an aspect you attach or even have a rule or job run that updates content based on the activeWorkflows values.

Yii: maximizing code reuse with per-user site configurations

The client I'm working for has a CMS written in Yii. Currently a part of their business is customizing the CMS to meet the specific needs of each customer. About 90% of the code is reused, essentially by copying and pasting from one directory to another. While I've been working on this project, I've had to merge changes in to the shared codebase several times.
All, or most, of these sites are hosted on the same server, and it would seem that it would make more sense to have a single login, that changed what features we showed based on the login. In some case that means overriding whole or partial views (eg, the _form.php might change from customer to customer) including the controller and model. Most of the time, it means adding a new controller for a bit of functionality written just for that client.
I've read about having both a front and backend site here: http://www.yiiframework.com/wiki/63/organize-directories-for-applications-with-front-end-and-back-end-using-webapplicationend-behavior but that doesn't seem to be the right fit (I don't want everyone coming to a different start php file, for instance)
Ideally, I'd have users log in, and get assigned a site id, which will filter data in the shared MVC objects, and will add in the ones specifically for them, or override the ones where necessary
Intuitively it seems like something like this would make sense:
Shared controllers go here:
/protected/controllers
Overrides and additions for client1 go here:
/protected/controllers/client1
or:
/protected/client1/controllers
But I'm not sure how to get Yii to do this in the most efficient and easy to manage way. Is this something that's going to work with Yii, or am I breaking it in ways unintended? If it will work, what's the best way to accomplish it so that it's clear to me six months from now, or some random developer who replaces me?
Do you know RBAM ?
With Role Based access you can profile your application in more-or-less granular way

Suggestions on addressing REST resources for API

I'm a new REST convert and I'm trying to design my first RESTful (hopefully) api and here is my question about addressing resources
Some notes first:
The data described here are 3d render
jobs
A user (graphics company) has multiple projects.
A project has multiple render jobs.
A render job has multiple frames.
There is a hierarchy enforced in the data (1 render job
belongs to one project, to one user)
How's this for naming my resourses...?
https:/api.myrenderjobsite.com/
/users/graphicscompany/projects
/users/graphicscompany/projects/112233
/users/graphicscompany/projects/112233/renders/
/users/graphicscompany/projects/112233/renders/889900
/users/graphicscompany/projects/112233/renders/889900/frames/0004
OR a shortened address for renders?
/users/graphicscompany/renders/889900
/users/graphicscompany/renders/889900/frames/0004
OR should I shorten (even more) the address if possible, omitting the user when not needed...?
/projects/112233/
/renders/889900/
/renders/889900/frames/0004
THANK YOU!
Instead of thinking about your api in terms of URLs, try thinking of it more like pages and links
between those pages.
Consider the following:
Will it be reasonable to create a resource for users? Do you have 10, 20 or 50 users? Or do you have 10,000 users? If it is the latter then obviously creating a single resource that represents all users is probably not going too work to well when you do a GET on it.
Is the list of Users a reasonable root url? i.e. The entry point into your service. Should the list of projects that belong to a GraphicsCompany be a separate resource, or should it just be embedded into the Graphics Company resource? You can ask the same question of each of the 1-to-many relationships that exist. Even if you do decide to merge the list of projects into the GraphicsCompany resource, you may still want a distinct resource to exist simple for the purpose of being able to POST to it in order to create a new project for that company.
Using this approach you should be able get a good idea of most of the resources in your API and how they are connected without having to worry about what your URLs look like. In fact if you do the design right, then any client application you right will not need to know anything about the URLs that you create. The only part of the system that cares what the URL looks like is your server, so that it can dispatch the request to the right controller.
The other significant question you need to ask yourself is what media type are you going to use for these resources. How many different clients will need to access these resources? Are you writing the clients, or is someone else? Should you attempt to reuse an existing standard like XHTML and classes/microformats? Could you squeeze most of the information into Atom? Maybe Atom with some extra namespaces like GDATA does it? Or is this only going to be used internally so you can just create your own media types, like application/vnd.YourCompany.Project+xml, application/vnd.YourCompany.Render+xml, etc.
There are many things to think about when designing a REST api, don't get hung up on what your URLs look like and you should really try to avoid doing "design by URL".
Presuming that you authenticate to the service, I would use the 1st option, but remove the user, particularly if the user is the currently logged in user.
If user actually represents something else (like client), I would include it, but not if it simply designates the currently logged in user. Agree with StaxMan, though, don't worry too much about squeezing the paths, as readability is key in RESTful APIs.
Personally I would not try to squeeze path too much, that is, some amount of redundant information is helpful both to quickly see what resource is, and for future expansion.
Generally users won't be typing paths anyway, so verbosity is not all that bad.

writing SEO-friendly pages that can be toggled public or private

our application wants to be able to create static, searchable pages based on user profile information, which would be linkable to other public profiles.
I am looking at LinkedIn as an example...it seems like they actually auto-generate the page to be a static file that is indexable and searchable.
Can someone suggest how we would do this? I am thinking there would need to be a cron job that runs and writes a the path and file name.
The user may want to keep the whole page private, in which case I imagine it would need to delete it.
There's alot of sub-requirements but that's the general concept and wanted to start getting ideas and feedback.
Thanks.
You can do without the cron job if you generate the static pages in real time whenever the profile information is created/updated or whenever user changed the setting to keep info public/private. This way you are not constantly looping through all users, and do not depend on another component (your cron job) to be running.
One alternative would be to adopt an explicit RESTful information architecture so that a profile resource ("page") is addressable with a permanent URL. The resulting resource could be a static page. Or not. That would be an implementation detail invisible to the search engine crawler and any web browser accessing the resource.
umnik700's answer is fairly dead-on if you're not considering issues related to authentication or who gets to see what. Consider the difference between the profiles you see when you're logged into Facebook versus those same profiles' publicly facing, searchable counterparts. Even MySpace, with a lot less consideration for search engine privacy, has viewability that is dependent on your relationship to the other person, defaulting, for private profiles, to "This profile has been set to private by the user" or something to that extent.
If you're looking to suddenly scale out a social tool where individuals are eliciting their personal information, I would suggest umnik700's answer (dynamically generate the content, but not the URLs, for public versions of the profile) with the following corollary: you need to be able to support privacy preferences varying from extremely strict to completely open, and default to a version that at least errs on the stricter, more private version of the profile. If you're just now pushing out searchable personal content when there never was any way to find it outside the site before, it's important not to abuse information given under different pretenses.
I know this probably requires maybe more scalability and added functionality than you were hoping this project would take, but to do otherwise could be most likely taken as a violation of your user base's tacit trust. Anyway, the best strategy to do this will probably require you to lean on your database more anyway, so it might be time to rework it a bit--including adding some privacy preferences.

How can I integrate users' logins from my site into phpBB?

I need some help with what is probably a newbie question in terms of modifying phpBB.
I have a whole system developed in PHP, and I would like to integrate phpBB so that people can navigate into the forums and post seamlessly, without logging in again.
Now, using the phpBB users table as the users table for my system (and having people register in phpBB instead of in my website) is not possible unfortunately (it'd take more work to redo our system than to build our own basic forum).
I'm assuming I can hack my way into making phpBB believe that a certain user ID has logged in, however, that user won't exist in phpBB's users table (which I'm assuming will cause it to error out pretty much everywhere).
All the tutorials and forum posts I could find implied having phpBB as the primary. I couldn't find anything to do it the other way around.
I'm guessing the only possible way to solve this is by having both tables relatively synchronized.
Now, provided that I can have both users table synchronized, what is the best way to integrate both sites, keeping my site's login and users table as the "primary" ones?
Also, is there anything in particular I should keep in mind when creating records in phpBB's users table? Or is it relatively straightforward to figure out? What tables should I be writing to, if there is more than one?
This is an old question so I'm sure you've worked something out by now, but if you need to refactor things in the future, this is entirely possible with authentication plugins in phpBB3:
http://wiki.phpbb.com/Authentication_plugins
I'm working on one now where phpBB is the "secondary" system, and it's going pretty well.
I just worked on this task today, after some investigation implemented an Authentication plugin Here is a good example Getting phpBB to accept Django sessions
I have integrated phpBB with a site before, however I used phpBB's login system/users table as the primary one as you said. Since phpBB is a pretty advanced forum software, it would be a pretty time consuming project to change its user and login system completely.
When I had to use the site's login as the primary one, I used PunBB. It was way simpler to modify PunBB.
If you absolutely have to use your own login as primary, and phpBB, then I agree with you in that the easiest way would be to keep the tables synchronized, and call both the login scripts when somebody logs in.
When you're inserting data into phpBB, the users table is pretty straightforward. Each entry has the basic info for a user, and if you have custom fields for the user profiles, they go into the profile_fields and profile_fields_data tables.
One tricky thing is how phpBB encrypts user passwords. I think you have to use phpBB's function called phpbb_hash($password) to do that. It's declared in the file
phpbb/includes/functions.php
For the phpBB login code, see funciton login_box in file phpbb/includes/functions.php
You can use the below to login into phpBB:
$result=$auth->login($username, $password);
if ($result['status'] == LOGIN_SUCCESS) {
echo "You're logged in";
} else {
echo $user->lang[$result['error_msg']];
}