I create my own users table with different name and different field name, i want to let kamailio use it as 'acc' table for peer users how can i do that?
acc table in kamailio is for accounting records (i.e., billing data).
I understand you want to use a different table for user profiles (the user account details such as username and password). If yes, then look at the readme for auth_db -- the module has parameters for setting column names:
http://kamailio.org/docs/modules/stable/modules/auth_db.html
The name of the table is given as parameter to authentication functions from the module (e.g., see auth_check() docs).
Be sure you disable table version check via version_table parameter from same module.
Related
how are you?
I'm working on a project that contains accounts with mailing list.
The account has 3 packages he can buy. Each package has it's own settings. e.g.: first package the user gets 1 email per day, and in second package he gets 5 emails per day.
Another feature that I want is the opertunity to override some of the package settings. Which means, for one account I'll set daily email limit as 7.
One more feature I need in this system is email providers. I want the first package to get emails only from first provider, second package from 2 providers and so on.
So I have a problem designing my DB.
I created table emailSubscriptions which has EmailID and name.
I created table accountsGroup which only contains GroupId and name.
I created table accounts which has AccountID, GroupID (foreign key), Email, password and investment. (According to his investment he gets his package).
I've created table accountsSubscriptions which has SUBSCRIPTION ID, AccountID, EmailID and IsActive.
I created table packages which contains PackageID, GroupID, from investment and to investment, and all other package settings e.g. maxEmailsPerDay ....
Of course the end user has. GUI that he can see his settings and edit what he can according to his current package. The admin of the users has GUI too.
Any way, now I got stuck.
I thought about adding to accounts all package columns and then when I want to send emails, I'll take the settings from the group and where ever it's not 0 / empty just override, but the problem is when some settings are 0 / 1, then the column is default 0 and if the groupSettings is 1 for something and I want to turn it off I can't. So this is the first problem
The second problem is with allowed emails subscriptions ... Same problem actually.
I thought about adding to package the allowedEmails, but then it means when ever I send the emails I need to use LIKE operator - and this is not good for runtime.
So I really need you help... Hope you can help me.
Thanks !!
The requirements part lacks clarity, I'd say.
But let's go for it anyway.
Let's extract entities from this messy field of things.
Each entity would generally means one table.
Start from Account.
Account has Subscriptions. It is not clear what's the relation here: if it is 1:1 ("account can have only one subscription") - then reference to it is a part of the Account entity, if it is 1:n - then you'll need a special Account-Subscriptions relation table.
Now Subscription - it is defined by SubscriptionType, or Package, so there must be a table that contains these records (these limits and whatever else you want). Account or Account-Subscription table would refer to it to define what subscription(s) the Account have.
Then Providers - they're referred by SubscriptionType/Packages. If there could be more than 1 Provider per Package/SubscriptionType - then you need additional Package-Provider realtion table.
And finally, the Overrides. That's a trickier part because of the weak requirements on it, but as soon as they're overriding the Package paremeters, I suggest to keep the entity structure same to the package.
You may even place it into the same Package table, sorting 'em out by date, or assign them weights, always keeping the default Package record with the lowest weight.
Then, when you create an override, you copy the whole default record except for the overridden fields, and assign it next weight (or current date), and when you query it - group it and get the MAX().
There's no Email entity itself - but you didn't mention it in your requirements sections whatsoever.
So, that's pretty much it: Accounts, Subscriptions, (optional) Account-Subscription, Packages, Providers, (optional) Package-Provider, (optional, may be incorporated into Packages) Overrrides.
Works for you?
I understand the concept of RBAC in ZF2, even with the ACL defined in config-files. But now I want to make some of my application modules available to individual users. E.g. user "foo#bar.com" may use modules A and C, user "bar#foo.net" has A and B available and so on. I can realize this in a MySQL database, but how could I do this in ZF2? I got an ACLService class with an "isAllowed" function where roles are compared, is this the right place to introduce some database?
In a few words a solution could be:
You introduce a user_role table and a role_privileges table.
In your user_role table you link user_id, email or username (a unique user identifier) to a role.
In your role_privileges table you link the role to one or more privileges (in your case a module, but it could also be a controller name or a route or whatever you want to manage).
You could also skip the role_privileges table and define the privileges in a config. That is decision is up to you...
If you don't want to write all the code then there are several ZF2 modules available that make this possible.
I want to configure Orion and Cygnus to store all data in a single table.
I know that I should configure the names of databe and table based in HTTP headers like so:
dbName=<fiware-service-header>
tableName=<fiware-servicePath-header>_<entityId>_<entityType>
I was told in this post to ask another question.
Cygnus uses the notified fiware-service and fiware-servicePath headers to compose the names of the different backend elements. Specifically:
MySQL
databases are called as <fiware-service>
table names are called as <fiware-servicePath>_<destination>
HDFS
HDFS paths are created as /user/<your_user>/<fiware-service>/<fiware-servicePath>/<destination>/<destination>.txt
CKAN
organizations are called as <fiware-service>
packages/datasets are called as <fiware-servicePath>
resources are called as <destination>
By default, <destination> is equals to <entityId>_<entityType>. This may lead, as described in the question, to the creation of a MySQL table/HDFS folder/CKAN resource per each notified entity.
Such a default destination generation may be changed by using an advanced feature of Cygnus, the pattern-based grouping; as the name suggests, the feature is based on finding (configured) patterns in the data, in order to group the context data showing the pattern. This feature allows, for instance, all the entities of a certain type are stored within a single MySQL table; or certain entities starting by a prefix are stored together in a HDFS file.
In order to activate this feature, edit the /usr/cygnus/conf/matching_table.conf file and add as many matching rules as you need; matching rules syntax is described here. Basically, the rules say "once the pattern-based matching is confirmed, use this new <destination> and this new <fiware-servicePath>":
<rule_id>|<list_of_fields_to_be_compared>|<regular_expresion>|<new_destination>|<new_fiware-servicePath>
Thus, a "store all the data in a MySQL table called 'my_unique_table'" rule would look like:
<any_unique_number>|<entityId>|.*|unique_table|my_
or:
<any_unique_number>|<entityId>|.*|_table|my_unique
Both rules are valid since MySQL table names are created, as already said, by concatenating <fiware-servicePath> and <destination>; in this case table name is equals to "my_"+_+"unique_table" or "my_unique"+"_table".
I have MySQL Database and have several tables in it. One, of course, is the users table for storing the username and passwords (which also has the rest of their information). For all the tables in the schema, I want to be able to grant users (or groups) permission to individual fields. Maybe an example will help:
There;'s a table called ACCOUNTS. In this table, the user fills out (and keeps up to date) all the data about their company (name, address, POC, etc). But I also want to have fields attached to this table that are read only for those users, such as LastPaymentDate (can't have them changing that!). Further, among those users, permissions differ. For example, the admin/superuser can change the name and address of the company, but standard users should not.
I'm thinking this might need to be done by making several Views for the table, one for each level of permission (group). I'm relatively new to MySQL, so I don't know if this is the best way. I can also see a lookup table that says which fields is allowed to view/edit.
My initial thought was to include in the comments (or the name of the field) a value from 0-5, and then the user would have a permission level (0-can't see; 1-Read only; 2-Read-write; 3-(not used); 4-(not used); 5-Edit/Delete the field itself.
Any suggestions? Views? Lookup table to determine which fields to display? Again, it'd not for the whole table, for each column within a table.
You can GRANT the rights to individual columns to a user, using this code:
GRANT SELECT (col1), INSERT (col1,col2) ON mydb.mytbl TO 'someuser'#'somehost';
Example taken from here:
http://dev.mysql.com/doc/refman/5.1/en/grant.html
Also there is no support for groups of users or SQL ROLES (which are groups of privileges) in MySQL.
I want to create a table called user_ports which will contain all the ports the user has opened in the database.
Instead of calling each colum as "port_80", "port_100"
I was wondering if its possible to enter it to a colum which will be called opened_ports as an array.
But if I would like to get all the users with port 80 opened, how can I do that?
As far as I can understand, you just need to have 2 columns in the user_ports table: user_id which will reference the appropriate user, and opened_port, which will describe the specific opened port. Then you should probably declare the (user_id, opened_port) pair as a primary key. With such table structure, you could select the ids of users that opened 80 port by the following query:
SELECT user_id FROM user_ports WHERE opened_port = 80;
You COULD store all of the ports opened by user as CSV in a single record, but this will:
require additional code that will deal with such trickery;
complicate and slow down your database queries;
denormalize your database (which should avoided).