as far as i can see its the one for creating a site. that's wy i wanted to take a look at the error report from soap, but i cant seem to find it.
use your script by hand sites_web_domain_add.php Logged successfull. Session ID:8e943a764fadd86173ad4012670e4b2d data_processing_error<br> <br> pm_process_idle_timeout_error_regex<br /> pm_max_requests_error_regex<br /> SOAP Error: pm_process_idle_timeout_error_regex pm_max_requests_error_regex
soap error: Till, I still think the problem has to do with the lack of such data. pm_process_idle_timeout_error_regex = ... pm_max_requests_error_regex = ... Is there a way to work around here? ie can not change the script, but I have access to the ispconfig server. kind regards Ben
Th script sites_web_domain_add.php has not been updated yet so there are some mising values in the params array. Just add the values mentione din the errr message to the $params array that you pass to the function.
Unfortunately, after adding the missing values to the param array it still present an error message data_processing_error. I have now, decided to go to P1. Not enough experience to detect programming errors. please report this one to your bug tracking system. It seems to me that al api users have this problem. Kind regard, Ben
All api issues have been fixed already a few days ago. Please see dev forum and bugtracker for details.
okay thanks for your reply. I would rather wait for the official upgrade version of P4, so I'm having a trouble-free solution. Thanks.
.htaccess not replacing the need for the login page? Hi, Just checking. I enabled the .htaccess , after authenticating I still need to login again on the default ISPconfig login page. Is that expected? Instead of generating a .htaccess you could use mod_auth_mysql in <Location /> like described in this feature request. http://bugtracker.ispconfig.org/index.php?do=details&task_id=3571 Gr, Justin
Till, This might be a bug. When I use password recovery program both values are changed in database: Code: mysql> SELECT username,password FROM client WHERE username='nedim'; +----------+------------------------------------+ | username | password | +----------+------------------------------------+ | nedim | $1$0E1ejve5$IaysbL2ItqEM9tcqYOZPa. | +----------+------------------------------------+ 1 row in set (0.00 sec) mysql> SELECT username,passwort FROM sys_user WHERE username='nedim'; +----------+------------------------------------+ | username | passwort | +----------+------------------------------------+ | nedim | $1$0E1ejve5$IaysbL2ItqEM9tcqYOZPa. | +----------+------------------------------------+ 1 row in set (0.00 sec) When I login in ISPConfig and change user password under Tools/Password and Language not both values are changed in database. Take a look at this Code: mysql> SELECT username,password FROM client WHERE username='nedim'; +----------+------------------------------------+ | username | password | +----------+------------------------------------+ | nedim | $1$0E1ejve5$IaysbL2ItqEM9tcqYOZPa. | +----------+------------------------------------+ 1 row in set (0.00 sec) mysql> SELECT username,passwort FROM sys_user WHERE username='nedim'; +----------+------------------------------------+ | username | passwort | +----------+------------------------------------+ | nedim | $1$eGSpQYe3$5peRc21g2tXywY7L8zMTk0 | +----------+------------------------------------+ 1 row in set (0.00 sec) No sure if this is a bug.
Only the table sys_user is used to authenticate users, the data in the client table is not used so it does not matter much if it is altered or not.
I understand this. I was manually syncing users on two different ISPConfig servers and I was not using the correct password field therefore the logins did not work...but you are right. Password field is not used but instead use Passwort field.
Roundcube not working properly after update Hi, I have updated my Debian Wheezy with ISPConfig 3 as soon as the update was released according to http://www.ispconfig.org/files/file/2-ispconfig/ I didn't check then, but now I am seeing "Soap Error : Unauthorized" when I go to Account settings in Roundcube. I checked for NginX error logs and found only "no user/password was provided for basic authentication, client:x.x.x.x, server: _, request: "POST /remote/index.php HTTP/1.1", host: "x.x.x.x:yyyy" I have enabled .htaccess protection. Could some one please help me with this issue ? EDIT: I read a comment from Till to add the IP but that didn't work and I am using NginX. So I had to disable the .htaccess protection by deleting the .htaccess files and removing the lines added in nginx ispconfig.vhost. Hope to see a better solution for all users. Thank you for developing a great product. Regards, Vikram
If you want to use the .htaccess protection and remote api, then you have to whitelist the IP address from where you access the api in the .htaccess protection. there is no other solution as external SOAP clients wont try to authenticate with http basic auth first.
Hi Till, Thanks for replying. Could you please guide me how to add/whitelist IP in .htaccess with NginX ? Regards, Vikram
Hi, can anyone confirm that the authentication though .htaccess is not replacing the ISPconfig login page when enabled?
Hi Justin, I can confirm , that behaviour is expected. AFAIU, .htaccess is the first line of defence before someone tries to start abusing the web interface. Someone more experienced can explain the detailed reason. Regards, Vikram
Hi Till, After updating to ispconfig 3.054p3, I face a new problem: I deactivated the original new installation user "admin" which user ID is 0. I then defined a new super admin with user name "superman" which user ID is also 0. Then, I define a new web site admin with user name "siteadmin" which user ID is 1. Now, user superman cannot change ispconfig3 system setting any more. How do I change superman's ID to 1 and also change siteadmin's ID to 2? Thanks in advance.
Your user is not the superuser of the panel, it is just a lower priviliged admin and such lower priveliged admins dont have all permissions to administer functions in the admin area anymore to prevent hacs wre the attacker injects an additional admin user. You can either undo your changes in the db if you havent added any websites on the serve yet and restore the original admin user or you disable the security features in the security_settings.ini. Chnaging the uid's will break the relations for all items that had been created by these users on your server, so if the server is already in use, the I dont recommend to change the ID's.