We are using a long grown installation of ejabberd.
We all are using a jid called {username}#xmpp.foo.bar
Is there any possibility to alias this host with the domain?
I want, that i can login with baz#foo.bar but internaly ejabberd should connect as account baz#xmpp.foo.bar. This would prevent me from migrating all users and have all users to change there clients.
thanks for help.
If you want the clients to be able to login specifying as JID baz#foo.bar, then a DNS query for foo.bar must direct the client to the machine that handles ejabberd, and also in ejabberd.yml you must have:
hosts:
- "foo.bar"
Then the question is, how to use the existing information? I propose to modify the database content, replacing the old host with the new host.
If you use some SQL database, you may know already what queries to perform. Or you can dump the database to a text file, replace xmpp.foo.bar with foo.bar, and load it again.
If you use the internal Mnesia database, you can dump it to a text file, modify as I mentioned before, and then load the modified text file.
Related
Every time I add an user, it gets duplicated to all virtual hosts. I've been facing this issue for a while and found a way to solve it, see this post, it says I have to configure a separate database to each virtual host.
What I can't understand is why Ejabberd has this default behavior in first place, what is the benefit to do so?
And what about mod_mam? How do I configure it to store each message into its own database?
My ejabberd.yml (mod_mam configuration at line 113)
Thank you. :)
and found a way to solve it
Since recent ejabberd versions, you can use the new SQL schema, and configure ejabberd to use it, see in
https://docs.ejabberd.im/admin/configuration/#relational-databases
What I can't understand is why Ejabberd has this default behavior in
first place, what is the benefit to do so?
One possibility is the saved space for very big servers. Of course, when having many small servers, it's preferable to use one single database.
And what about mod_mam? How do I configure it to store each message
into its own database?
It's the same with this module than with the other ones: if you configure it to use 'sql' storage, and you configured ejabberd to use a certain database for host "example.net", and a different one for "example.com"..., then mod_mam will use the correct SQL database to store the MAM messages depending on the user that wants to store them.
Se the first and second example configs in section https://docs.ejabberd.im/admin/configuration/#virtual-hosting
On the other hand, if you use the new SQL schema, you only define one database, so those doubts do not appear.
[also asked in https://github.com/processone/ejabberd/issues/2752 ]
Here's my situation: I have a file, homepage.php, that I want to allow my customers to host on their servers. homepage.php needs to somehow get information from my database, but I don't want my customers to have full access to my database. What's the best way to do this and how can I make it work?
I tried to do it by including the line:
require( "http://www.mydomain.com/connect.php" );
in homepage.php but I'm not sure if that's the right way and also, it gives me an error.
What error does it give you? Also that won't work because your server parses the PHP and send back the result, rather than including the source code like you want.
Easy solution
Have a read-only account, and give those details out to your customer's pages.
Then they can set up the mysql connection with the IP/exposed port of your mysql server and log-in from there.
Better solution
Have accounts for each customer, so privileges can vary accordingly, otherwise same as above.
Best solution
Expose access via a SOAP service. If you have enough customers and they're developing with you, an API is invaluable.
Without the warning it is hard to troubleshoot the connection issue although I bet it might have something to do with it looking at localhost versus the IP of the machine where the database resides.
The best solution is to have an ini file that has the username and password in it for each individual customer and have the connect.php file look for the ini file on that customers local webserver. You can then configure the priveleges for each account to have only select access to certain tables, or update priveleges to certain users, etc.
Also if your customers will be building their own code around yours, developing a SOAP service might be useful.
We are storing sensitive data in MySQL, and I want to use AES_ENCRYPT(data, 'my-secret-key-here') and then AES_DECRYPT which works great. My biggest question is how do I secure the key? Previously I just wast storing the key in a web PHP file, so something like:
define("ENCRYPTION_KEY", 'my-secret-key-here');
This really doesn't work though, as our MySQL server and web server are the same physical machine, so if somebody gains access to the server, they can get both the encrypted data stored in MySQL and the key.
Any ideas? I am thinking I need to move the key to a separate server, and read it in remotely. Or, what about generating the encryption key dynamically for each piece of data. For example taking the customer_id and running md5 on it, and then using that as the key.
Put the secret key in a file, change the file owner to the same user as the web server. Remove all permissions on the file for the group and everyone else.
There's a similar question on Superuser (https://superuser.com/questions/139393/linux-file-permissions-access-control-query) -- I'm sure you could get better help over there, or just by Googling for more information about file permissions on the system you're running.
A couple options:
Save the decryption key to a file with proper permissions
If you really want to store the key offsite, "mount" a drive from a different machine. You'd still need to setup permissions properly though.
Bottom line is the master password has to be accessible to the server - which means there's no way to completely wall it off. The best you can do is set user/group permissions on it and make sure it's outside the web root.
If you don't need the ability to decode the value back to plain text (ie if you are just comparing values like a password) consider using a hash instead.
We need to deploy application(developed by Java) WAR file in client place which make use of MySql 5.0. But we would like to restrict the client (the application owner, not the webpage visitor) from modifying any data in the database. Is there any way to protect data. The client can make use of the application but they should not be able to change any value in database. How to do that?
Manage Role/User permissions
Create an sql user (you should already have one), which will have only SELECT permission. So it would be something like
GRANT SELECT ON db_base.* TO db_user#'localhost' IDENTIFIED BY 'db_passwd';
http://kb.mediatemple.net/questions/788/HOWTO:+GRANT+privileges+in+MySQL
http://blog.wl0.org/2010/01/managing-mysql-grants/
http://www.ntchosting.com/mysql/grant.html
Check links below for further reading
FOR MySQL
Best Practice for Designing User Roles and Permission System?
http://www.databasejournal.com/features/mysql/article.php/3311731/An-introduction-to-MySQL-permissions.htm
http://www.devshed.com/c/a/MySQL/MySQL-User-Account-Management/
Can't set permissions on MySQL user
http://www.aquafold.com/d7/docs/BD5C99E4-3B55-C812-8318-6338A9A89ED9.html
FOR SQL Server.
http://www.databasejournal.com/features/mysql/article.php/3311731/An-introduction-to-MySQL-permissions.htm
http://www.mssqlcity.com/Articles/Adm/SQL70Roles.htm
http://www.sql-server-performance.com/articles/dba/object_permission_scripts_p1.aspx
https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-1061781.html
http://www.databasejournal.com/features/mssql/article.php/2246271/Managing-Users-Permissions-on-SQL-Server.htm
This is impossible; if you deploy the application at the client, he will have the credentials and will be able to log into the MySQL database and pretent he is the application. And thus he can make any change to the database that your application can.
The only way to solve this securely is to make a tier between the client and your MySQL database, and make sure that you control this so that it is only possible to make 'legal' changes.
Just write the code accordingly so that the user doesn't have any chance to modify the database? I.e. the code doesn't execute any INSERT or UPDATE and/or controls the access based on a login/role.
I honestly really don't forsee any problems here, or the code must be prone to SQL injection attacks.
Update: The above answer is actually irrelevant since the question is clarified. Turning into Community Wiki.
First off, I realize that there is no such thing as a perfectly secure solution (and even if there were, its usability would be crap).
That said, how do you protect your MySQL database from being compromised by someone downloading your code and picking through it? Based on my experience with PHP, it seems obligatory to store it within the code at some point or another, which sends up flags for me. I can see where refactoring to obfuscate variable, constant, and (user-defined) function names could be beneficial, but in the end it'd still be possible to trace through it and find the file with the DB login information.
Ideas?
Usually the MySQL auth information is stored in an external configuration file. The MySQL user used by the web-based app is given limited permissions such as SELECT, INSERT, UPDATE, DELETE and not given permissions such as ALTER, DROP, DELETE. If you want to release the code to the public you would not include your private config file, but a generic/instructional/minimal config file instead.
Storing the MySQL auth info in an encrypted format is somewhat silly, as you'd need to store the private key / unencryption locally as well. If it is trivial for an unauthenticated user to view the code or configuration files on your server the problem isn't the code - it's your server setup & config.
Security can be assisted by storing any hard-coded information (in config files or scripts) outside of the web-root, and by suppressing (on the production code) error messages. That way, hopefully, your users won't see that userValidate() expects exactly three paramaters.
pygorex1 is correct, you should use external configuration files where "external" means a file outside the web root. So even if there would be a configuration error in your web server which would allow the user to see your source code, they would not be able to see the database credentials since they cannot be accessed directly via the browser.
pygorex1 is also right on the user permissions. Limiting the mysql user's access to a minimum is always preferred. Even if a hacker would get the your mysql password and username, he would not be able to do significant damage if the user permissions are only limited to eg SELECT-queries. One thing he forgot to mention was that the mysql user should only be allowed to log in from localhost (or from whatever host the web application is on), never use wildcards in the allowed hosts.