I am building an application logic with symfony2 that requires some form of secuirty.
Application logic:
There are "Translations", and "Languages" table some users, should be allowed to edit certain parts of the "Translations" table for example. User1 can edit translations that are in French (fr category). Other user can edit translations that are in Spanish etc... And some user might be edit both of those translations. I also need to make some users to be able assign those "Translations" to other users.
So I guess the most suitable way to achieve this would be ACL system. But there's one thing that is worrying me, there will be a lot of translations - hundreds of thousands, so if I assign ACL to each user and each translation, the ACL table grows really large, what I would like to do is assign category(Language from Language table) instead of translation, so that certain user would be able to edit all translations with assigned category (en, fr, es ... etc..). How could I achieve something like this?
I think I can't get away without ACL, but I think it's not enough, maybe combination of ACL and voters? But I don't how to put everything together.
Related
I am developing an MVC framework (please don't question that, I know..) and currently designing a translation mechanism to maximally ease translation of applications, so far I have a lang folder which contains translation files for different pages
./lang/en/system.php
./lang/es/system.php
./lang/fr/system.php
and so on. Lets say this file contains translations of system messages such as
./lang/en/system.php
<?php
return array(
'yourIP' => 'Your IP address is :1'
);
To access that in a page I will use a facade class Lang, which will fetch the file based on the selected language (stored in session) and give me the translations.
Controller
public function index() {
return new View('index', ['translations' => Lang::get('system')]);
}
View
<h1><?= $translations->get('yourIP', System::getClientIP()) ?></h1>
This seems to work pretty fast as I can group translations efficiently in separate files for separate modules/pages.
The problem I am trying to solve now is with translating models. For example lets say I'm building a multilingual blog and saving posts in a database. Each post will need translations of its own, but theoretically there can be an unlimited amount of posts. The current method I'm using does not seem very practical.
What I will have to do is create a child directory and store translations like
./lang/en/posts/post-1.php
./lang/en/posts/post-2.php
...
./lang/en/posts/post-n.php
And that would be for every language, where in this file I will store all translatable (is this a word?) fields of the model and will load it in the model's constructor.
Problems regarding this solution:
The filesystem will get stuffed with lots of very small files - I'm not really a filesystem expert and I would like to ask if having a large amount of small files like that can cause harm to the filesystem itself including slowdowns of reads and such.
There will be n filesystem reads when retrieving a set of models, where n is the number of models. The hard drive is the slowest component in a computer, performing lots of FS reads in a script will present a significant slowdown, now with SSDs maybe not that much but still not a minor problem.
The other solution I came up with is use an additional system database table, which will store translations by table and primary key, something like
table INT
model_pk INT
lang INT
translations TEXT
where table will be a crc32 encoded number of the name of the table which the translations belong to, model will be the PK (id) of the model, lang no need to explain and translations will be a serialized string containing all translatable properties.
Problems with this approach:
Forces developer to use a database and obligates them to have a certain table (currently the framework does not require you to have a database and thus there are no system tables when you actually use one).
models with composite primary keys will not be able to benefit from this since the model column can not store a composite key, so only models with a single column primary key will be translatable.
These are just my observations and thoughts, I may be wrong or I may be missing something. I'm posting this question to get advice on which solution will be less problematic from someone with greater experience or propose a completely different one, I'm open to everything.
If you need to build something great first you must understand that what you make until now is called localization (setting app language which will case translation of static data) but you still need to make translation (which mean translate dynamic data like data came from database)
For more details http://content.lionbridge.com/the-difference-between-translation-and-localization-for-multilingual-website-projects-definitions/
For more about localization: https://laravel.com/docs/5.3/localization
and see also https://github.com/mcamara/laravel-localization
For more about translation you can find this package For Laravel Framework interested https://github.com/dimsav/laravel-translatable
I know that the title of this question is not intuitive, but let's go to the question.
I've designed a "core system" for all my backend web apps (control panels, systems to manage clientes, balances, etc). This "core" is the start point for developing new modules according to the new system specific needs, but I always keep the "core modules":
Users (to manage user roles)
User type (in distinct systems there are distinct kinds of users, so it's nice to manage them dinamicly)
Modules (to create new modules and add permissions to them)
Dashboard
My main question is for the User module. Since it has the default columns
UserId; Name; Login; e-Mail; Password; isRoot; isPowerUser; UserTypeId
I want to create new control panels and apps, but dont want to change this table to keep the "core" updatable with an easy process in the future. My ideia of design is to create table named User_Extra which will contai all the extra columns for this specific user.
Is this a good approach? I'll also will create a new class named UserExtra.class.php.
If u want to take a look at the project to get the ideia: https://bitbucket.org/alexandrekop/akop-core
Imagine looking at your database schema, and seeing a table named "user_extra" with a bunch of fields that aren't related to each other in any way and each field is related to a different module, does it feel 'right'?
My suggestion is to split the extra fields into relevant tables, possibly per module, or per logical group.
For example, if one module was related to addresses, you would have a table "user_addresses", with things only specific to the address of the user.
I am a pretty good programmer but I am not great when it comes to designing system architectures. I have a pretty simple inventory system I am making however I would like to know a good way to structure it.
I have around 20 pieces of equipment that users can [View All | Update | Delete | Add] each of them. However I have different access levels for different equipment (which needs to be dynamic, change who can view or delete what).
For example, one piece of equipment would have?
addPart1.php
removePart1.php
updatePart1.php
index.php (view all parts)
addPart2.php
removePart2.php
updatePart2.php
index.php (view all parts)
For all parts? Im confused on trying to design a good, scalable and efficient structure.
An access control list (ACL) is a list of permissions attached to an object. An ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed to be performed on given objects. In a typical ACL, each entry in the list specifies a subject and an operation (e.g. the entry (Alice, delete) on the ACL for file WXY gives Alice permission to access file WXY).
Source: WIKI
Please take a look at:
http://dev.juokaz.com/php/acl-made-easy-part-1 (tutorial on ACL)
http://sourceforge.net/projects/tackle/
You could categorize your products table, so each kind of equipment has its own "category" or "group". You can do that by assigning a "group_id" to each product (on a new column on your table). If you have 300 products, some of them will be on group 1, others on group 2, etc.
Then, on your users table (the one that contains usernames/password for each admin), you need to add an additional field called "group_permissions". On that field you have to store a list of "group ids" each user can view. You can store those permissions separated by comma.
$permissions = '1,2,5,9';
Each time a user access one of your PHP files, you get its permissions and do a simple check like this:
SELECT * FROM products WHERE group_id IN($permissions)
That will only return the products that user has permissions to edit or view. This will vary depending of your interface.
To understand my confusion/question, let me first give a quick overview of the site I'm building: The site has a homepage, and 7 category pages, each with the same/similar layout.
On most category homepages (eg "Dining"), you can do a search (ie a search for restaurants), which will take you to a results page. This will have the same/similar layout as the... "Theaters" search result page...etc etc.
So - although there are a lot of sections, there are not a lot of page layouts.
Question: I'm not sure if I should create separate controllers for each, and just use the same CSS for them? Or if I can use the same view file, but populate each content area on the page differently based on the url/action..etc?
They'll all reference different & multiple tables in the database - for instance, restaurants will reference the restaurants table, the cuisines table, the zip_codes table...etc. Theaters might reference the "movies" table, the zip_codes table...etc etc etc
But - I also want an admin tool for some - ie "restaurants/edit" or "theaters/edit" ...etc - not ALL the pages will have admin for that specific url - ie "outdoors" might just be "businesses/edit" or something generic... I don't know - I'm confused as you can tell.
Any help is GREATLY appreciated. I've read a lot about the technical things to do w/ CakePHP, but I can't find any good resources for general project structures for varying scenarios.
You can answer this yourself. Suppose you implement separate controllers, models and views for each, how do they differ? If they only differ in the table names and labels/strings that they use, then you can use just one generic controller. But, if they are different in other ways (e.g. the Restaurants model has a totally different relationship structure than a Movie model) then use separate controllers.
To prevent too many repetition between controllers and view files when you do use separate controllers, try to push functionality in a common base controller (e.g. AppController, of create your own base controller based on AppController that your MoviesController and RestaurantsController and so on will derive from). Push generic view code into elements.
A word about CSS: Of course you can (and should) reuse that. It's mostyly separate from the view. Just use sensible class names and id's in your views and the CSS will be easy to reuse.
If you are still unsure, I'd go with separate controllers. It may be more work but it will be cleaner and easier to debug. Use the above suggestions to avoid repetition.
-group elements that will share among all site in a layout (ie. site css, site common js library)
-make a view for each of your category(page) (ie. dining page, theater page, restaurants page) and put there page only stuff (ie. theater js, theater includes) there
- in theory, every vew should have a controller and model, so you have to make them separate.
anyway url like "restaurants/edit" or "theaters/edit" actually means model "restaurant", operation "edit" in your controller file.
I suggest you read the blog tutorial from cakephp site, you that should answer all your confusion
I'am working on a PHP + MySQL Social Networking application, now i need to setup different access control (read,create,edit,delete) for global (all items) and/or self items (item which created by themselves) for each module to group or specific user.
Does anyone has suggestions in doing this (table structures, etc)?
okay here i provide more detail, currently i have a tbl_module, tbl_user, and tbl_user_role. Each user and role can have different access to specific module.
read
update
create
delete
and devided by global access or self only (own account or records created by themselves).
and my current approach: i create another table to hold the access detail:
acl_uid
mod_id (fk module uid)
target_id (fk user uid or role uid)
acl_type (user/role to identify the target id reference)
acl_read
acl_update
acl_create
acl_delete
acl_read, acl_update, acl_create, acl_delete value ranges:
0 deny
1 allow
2 refer to lower priority check (if user has value 2 then refer to role)
3 self only
i believe that theres more efficient way to solve this, or may an improvement to my current approach.
thanks for your responses.
That's a pretty broad question, so you're likely to only get very broad answers.
Most CMS systems have a table that lists the types of content that can be produced on the system.
Another table describes how each type of content is displayed (on the front page, on individual blog pages, etc).
Another table gives each user one or more "user types" or "groups" such as admin, unregistered, moderator, etc.
A last table is an access table of sorts - it shows what each group has power to do, including the types of content it can create, edit, publish, etc.
I recommend you spend a little time studying the database schemas of other CMS software, such as Slashcode, Drupal, or one of the other millions of CMS systems.
-Adam
It is in fact a very broad question. Assuming you have a clear separation of application tiers (eg, using MVC), then this is the sort of stuff going in the business layer.
Taking your direct requirements, it could be fairly simple. In your users table, have a hasEdit, hasView, etc. For each item, attach a userid to it representing the creator. In the business layer, the rule is they have edit permission if they are the creator, or they have hasEdit = true.
Taking it up a notch, if you have different types, and the hasEdit permission is per-type, you need another entity for that.
userPermission
userPermissionId
userId (FK)
typeId (FK)
hasEdit (boolean)
hasView
etc..
To find out if they have permission to edit, you check if either they're the owner, or look up that items type and the current user in the userPermission table, and check hasEdit. You could make additional rules, like putting a global hasEdit in the user table. Or representing global hasEdit by an entry in userPermissionId with a NULL typeId.
This can get way more complex, using roles and variable numbers of permissions.. it all comes down to your requirements. You need to carefully spec out your business requirements (come up with a bunch of use cases), and then you can design from there. As is, there's really not enough information to come up with anymore than I've outlined here (and even this is probably not exactly what you need).
I like to use a kind of firewall rules approach or similarly a mysql tables rules approach: you can grant users or groups of users certain rights on certain objects or groups of objects. Make each rule be a row in your rules table. When you need to do an action like edit, you can inner join on your rules table for the current user, current user's group, the boolean edit column and the object id or object group. If you get any rows back then the permission is granted.
There are quite a few ways of designing security, and I've liked quite a few for different situations. There's UNIX-style user-group-other. I happen to like PmWiki's security model.
I developed a website which used user-role-permissions structure similar to Apache. With that website, I used a template system that used a header include file and a footer include file to wrap the page contents with the "standard stuff". A page with restricted content could set a variable to the required permission, that the header script looks for, and if set, calls an auth function that checks the user belongs to a role that permission.
The nice thing about using the user-role-permissions model is if most of your users fall into neat categories of authorization, setting the authorization for a user is a simple matter of adding the right role to that user. The permissions are linked to roles, not users directly, so you can adjust the permissions of entire classes of users easily.