Unable to Log In or use Reset password in Mollify 2.2.2

[GoogleCodeExporter]

So the new version 2.2.2 i cannot, after update, (using the backend update) log 
back in or any of my other users can't log in OR use the password reset 
feature, it gives out "Request Failed" and error in PHP Error Log:

PHP Fatal error:  Call to undefined method ConfigurationDao::changePassword() 
in 
C:\PATH_TO_MOLLIFY\backend\plugin\LostPassword\LostPasswordServices.class.php 
on line 33

Have i missed something again on how to update/upgrade to Mollify 2.2.2?

Original issue reported on code.google.com by Logic...@gmail.com on 29 Oct 2013 at 7:24

[GoogleCodeExporter]

I'm guessing the hash change resulted this and thus all the old passwords are 
now invalid, but there is no way to log back in to change the password OR no 
one can use the password reset feature to get a new password (and that should 
result a new hash in the database?)

Original comment by Logic...@gmail.com on 29 Oct 2013 at 7:34

[GoogleCodeExporter]

This was already fixed, but did not end up in the 2.2.2 release. I'll make a 
new release, but attached is the new version of the 
LostPasswordService.class.php.

What is the error when you try to log in? I tested the update quite many times, 
it is supposed to work so that old password is left there and new hash is 
stored whenever user logs in and does not have it. After that, the old is not 
used anymore.

Original comment by samuli.j...@gmail.com on 29 Oct 2013 at 7:44

Attachments:

• LostPasswordServices.class.php

[GoogleCodeExporter]

It simply gives "Incorrect Username or Password" below on that long gray line

Original comment by Logic...@gmail.com on 29 Oct 2013 at 7:46

[GoogleCodeExporter]

Is there anything in the PHP error log?

Original comment by samuli.j...@gmail.com on 29 Oct 2013 at 7:49

• Changed state: Accepted

[GoogleCodeExporter]

The new LostPasswordService.class.php does not work either, error code is:

MOLLIFY ERROR: PHP error #2, is_readable(): open_basedir restriction in effect. 
File(/dev/urandom) is not within the allowed path(s): 
(LIST_OF_PHP_OPEN_BASEDIR_EXCEPTIONS) 
(C:\PATH_TO_MOLLIFY\backend\vendor\phpass\PasswordHash.php:51)
{0:{function:globalErrorHandler, args:{0:2, 1:is_readable(): open_basedir 
restriction in effect. File(/dev/urandom) is not within the allowed path(s): 
(LIST_OF_PHP_OPEN_BASEDIR_EXCEPTIONS), 
2:PATH_TO_MOLLIFY\MOLLIFY\backend\vendor\phpass\PasswordHash.php, 3:51, 
4:{count:16, output:}}}, 
1:{file:PATH_TO_MOLLIFY\backend\vendor\phpass\PasswordHash.php, line:51, 
function:is_readable, args:{0:/dev/urandom}}, 2:{file:...

This error continues, if you need the full one, tell me, but it seems to be 
just repeating the same stuff over and over i copy/pasted above.

Original comment by Logic...@gmail.com on 29 Oct 2013 at 7:52

[GoogleCodeExporter]

@ "Is there anything in the PHP error log?"
By just trying to log in without using password reset, there is nothing in PHP 
Error Log, but there are errors when trying to use the new class or the old one.

Original comment by Logic...@gmail.com on 29 Oct 2013 at 7:53

[GoogleCodeExporter]

Wait a minute, i think there is while user is trying to log in, it gives:

MOLLIFY ERROR: ServiceException: INVALID_CONFIGURATION=User auth info missing 25

and

MOLLIFY ERROR: 
{0:{file:C:PATH_TO_MOLLIFY\backend\include\Authentication.class.php, line:114, 
function:auth, class:Authentication, type:->, args:{0:{id:25, 
name:USERNAME_IN_PLAIN_TEXT, lang:, email:MAIL_IN_PLAIN_TEXT}, 1:, 
2:PASSWORD_IN_PLAIN_TEXT}}, 
1:{file:C:\PATH_TO_MOLLIFY\backend\include\services\SessionServices.class.php, 
line:59, function:login, class:Authentication, type:->, args:{0:... continues 
and repeats itself.

Notice the plain text things.

Original comment by Logic...@gmail.com on 29 Oct 2013 at 8:02

[GoogleCodeExporter]

Seems like the update script did not make any inserts into the "user_auth" 
table, can you check that?

There is one possible explanation to this, but I do wonder how did it work on 
my test site. The original insert clause is this:

INSERT INTO `{TABLE_PREFIX}user_auth` (user_id, type, salt, hash) SELECT id, 
auth, '-' as salt, '-' as hash FROM `{TABLE_PREFIX}user`;

My theory here is that since the column names are not identical, the insert 
will not work. If you can try running manually this clause:

INSERT INTO `{TABLE_PREFIX}user_auth` (user_id, type, salt, hash) SELECT id as 
user_id, auth as type, '-' as salt, '-' as hash FROM `{TABLE_PREFIX}user`;

(naturally remove or replace the {TABLE_PREFIX}. I'll run few tests with this 
before I make new release, but running this script should fix the login 
problems.

Original comment by samuli.j...@gmail.com on 30 Oct 2013 at 5:29

[GoogleCodeExporter]

I also saw in the logs:

PHP error # 2, is_readable (): open_basedir restriction in effect. File 
(/dev/urandom) is not within the allowed path (s):.............

to solve this problem, I add in php_admin_value open_basedir 
".......:/dev/urandom:"

Original comment by SerChe...@gmail.com on 30 Oct 2013 at 5:29

[GoogleCodeExporter]

There are inserts in "user_auth" table in MySQL, just in case tho, i deleted 
them and ran your script, the results are the same, still unable to log in.

Original comment by Logic...@gmail.com on 30 Oct 2013 at 8:14

[GoogleCodeExporter]

Ok, i got something, it seems to be like this:
I make your insert into the "user_auth" table and whenever i log in with a 
user, it disappears from the "user"auth" table for some weird reason.
I noticed this when i saw some fields were missing from user_auth table after 
some time, i wondered what caused them, i noticed they disappear every time 
after a user tries to log in and gets the error.

So in short: Trying to log into Mollify makes the corresponding user_id entry 
disappear from "user_auth" table. For example my admin user_id is 20 and every 
time i try to log in with it, it disappears from the table. Adding it back wont 
make difference, because it goes away again after trying to log in.

Original comment by Logic...@gmail.com on 30 Oct 2013 at 8:25

[GoogleCodeExporter]

Strange... Would it be possible for you to enable the debug logging (add 
"debug"=>TRUE in configuration.php, clear the PHP log, rerun the script and 
then try logging in. And then get me everything there is in the log. That way I 
could see what's going on with the auth_table.

Original comment by samuli.j...@gmail.com on 30 Oct 2013 at 8:30

[GoogleCodeExporter]

This error occurs first when i run your script and all the rows in the table 
"user_auth" are there (user still can't log in):

MOLLIFY ERROR: PHP error #2, is_readable(): open_basedir restriction in effect. 
File(/dev/urandom) is not within the allowed path(s): 
(OPEN_BASEDIR_DIRECTORY_LIST) 
(PATH_TO_MOLLIFY\backend\vendor\phpass\PasswordHash.php:51)
{0:{function:globalErrorHandler, args:{0:2, 1:is_readable(): open_basedir 
restriction in effect. File(/dev/urandom) is not within the allowed path(s): 
(OPEN_BASEDIR_DIRECTORY_LIST), 
2:PATH_TO_MOLLIFY\backend\vendor\phpass\PasswordHash.php, 3:51, 4:{count:16, 
output:}}}, 1:{file:PATH_TO_MOLLIFY\backend\vendor\phpass\PasswordHash.php, 
line:51, function:is_readable, args:{0:/dev/urandom}}, 
2:{file:PATH_TO_MOLLIFY\backend\vendor\phpass\PasswordHash.php, line:213, 
function:get_random_bytes, class:PasswordHash, object:PasswordHash, type:->, 
args:{0:16}}, 
3:{file:PATH_TO_MOLLIFY\backend\include\auth\PasswordHash.class.php, line:25, 
function:HashPassword, class:PasswordHash, object:PasswordHash, type:->, 
args:{0:MOLLIFY_SERVER_SALTUSER_PASSWORD_PLAINTEXT5270c5809f4621.29438657}}, 
4:{file:PATH_TO_MOLLIFY\backend\include\configuration\ConfigurationDao.class.php
, line:78, function:createHash, class:Mollify_PasswordHash, 
object:Mollify_PasswordHash, type:->, args:{0:USER_PASSWORD_PLAINTEXT}}, 
5:{file:PATH_TO_MOLLIFY\backend\include\auth\AuthenticatorPW.class.php, 
line:26, function:storeUserAuth, class:ConfigurationDao, 
object:ConfigurationDao, type:->, args:{0:25, 1:USERNAME_PLAINTEXT, 2:, 
3:USER_PASSWORD_PLAINTEXT}}, 
6:{file:PATH_TO_MOLLIFY\backend\include\Authentication.class.php, line:136, 
function:authenticate, class:Mollify_Authenticator_PW, 
object:Mollify_Authenticator_PW, type:->, args:{0:{id:25, 
name:USERNAME_PLAINTEXT, lang:, email:USER_EMAIL_PLAINTEXT}, 
1:USER_PASSWORD_PLAINTEXT, 2:{user_id:25, type:, hash:-, salt:-}}}, 
7:{file:PATH_TO_MOLLIFY\backend\include\Authentication.class.php, line:114, 
function:auth, class:Authentication, object:Authentication, type:->, 
args:{0:{id:25, name:USERNAME_PLAINTEXT, lang:, email:USER_EMAIL_PLAINTEXT}, 
1:{user_id:25, type:, hash:-, salt:-}, 2:USER_PASSWORD_PLAINTEXT}}, 
8:{file:PATH_TO_MOLLIFY\backend\include\services\SessionServices.class.php, 
line:59, function:login, class:Authentication, object:Authentication, type:->, 
args:{0:USERNAME_PLAINTEXT, 1:USER_PASSWORD_PLAINTEXT}}, 
9:{file:PATH_TO_MOLLIFY\backend\include\services\SessionServices.class.php, 
line:51, function:authenticate, class:SessionServices, object:SessionServices, 
type:->, args:{}}, 
10:{file:PATH_TO_MOLLIFY\backend\include\services\ServicesBase.class.php, 
line:59, function:processPost, class:SessionServices, object:SessionServices, 
type:->, args:{}}, 
11:{file:PATH_TO_MOLLIFY\backend\include\MollifyBackend.class.php, line:82, 
function:processRequest, class:ServicesBase, object:SessionServices, type:->, 
args:{}}, 12:{file:PATH_TO_MOLLIFY\backend\r.php, line:63, 
function:processRequest, class:MollifyBackend, object:MollifyBackend, type:->, 
args:{0:Request}}}

This error occurs second when the user row disappeared after the first try of 
the log in (user still can't log in):

MOLLIFY ERROR: ServiceException: INVALID_CONFIGURATION=User auth info missing 
25   (this nr 25 here is the user id)

MOLLIFY ERROR: 
{0:{file:PATH_TO_MOLLIFY\backend\include\Authentication.class.php, line:114, 
function:auth, class:Authentication, type:->, args:{0:{id:25, 
name:USERNAME_PLAINTEXT, lang:, email:USER_EMAIL_PLAINTEXT}, 1:, 
2:USER_PASSWORD_PLAINTEXT}}, 
1:{file:PATH_TO_MOLLIFY\backend\include\services\SessionServices.class.php, 
line:59, function:login, class:Authentication, type:->, 
args:{0:USERNAME_PLAINTEXT, 1:USER_PASSWORD_PLAINTEXT}}, 
2:{file:PATH_TO_MOLLIFY\backend\include\services\SessionServices.class.php, 
line:51, function:authenticate, class:SessionServices, type:->, args:{}}, 
3:{file:PATH_TO_MOLLIFY\backend\include\services\ServicesBase.class.php, 
line:59, function:processPost, class:SessionServices, type:->, args:{}}, 
4:{file:PATH_TO_MOLLIFY\backend\include\MollifyBackend.class.php, line:82, 
function:processRequest, class:ServicesBase, type:->, args:{}}, 
5:{file:PATH_TO_MOLLIFY\backend\r.php, line:63, function:processRequest, 
class:MollifyBackend, type:->, args:{0:Request}}}

The second error just keeps repeating itself and the row in "user_auth" table 
is gone.

Original comment by Logic...@gmail.com on 30 Oct 2013 at 8:47

[GoogleCodeExporter]

I got the same error after upgrading to the newest version. The user_auth row 
is gone after i try to login 

Original comment by schnett...@gmail.com on 30 Oct 2013 at 9:01

[GoogleCodeExporter]

So you have the same thing as in: 
https://code.google.com/p/mollify/issues/detail?id=485

Can you try adding the htaccess entry and see if it helps. I need to make a 
correction so that there is a db transaction that prevents losing the old row 
if creating new one fails.

Original comment by samuli.j...@gmail.com on 30 Oct 2013 at 9:06

[GoogleCodeExporter]

To summarize, adding this to htaccess should fix the hash generator:

<DirectoryMatch "/yoursite/here/">
    php_admin_value open_basedir "/dev/urandom"
</DirectoryMatch>

Latest version should already have the warning suppression (@-sign in 
include/vendor/phpass/PasswordHash.class line 51), so I guess it won't help 
here.

I chose PHPass because it seemed like a password hash generator that should 
work on all servers, many other hash generator seem to require PHP server 
version greater than 5.3, which many service providers not offer.

Original comment by samuli.j...@gmail.com on 30 Oct 2013 at 9:13

[GoogleCodeExporter]

I never had .htaccess on Mollify and really don't want to give any extra 
permissions to Mollify script for security reasons to be able to run .htaccess 
commands, this was the entire reason i chose Mollify in the first place, no 
extra permissions, all the script files could be read only when in working 
order etc.

I tried the DirectoryMatch, but it didn't help, reverting back to Latest oldest 
Mollify and using it as long as i can.

Original comment by Logic...@gmail.com on 30 Oct 2013 at 9:28

[GoogleCodeExporter]

It's not a script or a command. That htaccess simply says that it is ok to 
access /dev/urandom/ in your server. I just had no problems with this myself.

I really don't know why they have chosen to get random data from /dev/urandom, 
and did not see this coming. Perhaps PHP random generator is not good enough, I 
only know that PHPPass is widely used and suggested lib for password hashing. I 
have to see what options there are at the moment, can I remove the urandom 
thing or should I use some other lib, don't know...

But you do what you do, if older version suits you, go ahead.

Original comment by samuli.j...@gmail.com on 30 Oct 2013 at 9:34

[GoogleCodeExporter]

I have a windows server, I'm pretty sure i don't have /dev/urandom

Original comment by Logic...@gmail.com on 30 Oct 2013 at 9:41

[GoogleCodeExporter]

Yes I see that, I'm pretty surprised (disappointed) they did not think of that 
kind of thing. I'll fix this somehow.

Original comment by samuli.j...@gmail.com on 30 Oct 2013 at 9:45

[GoogleCodeExporter]

I made a new release with attempted error recovery (not sure if it works or not 
since my environment does not have this restriction), and as a failsafe option 
there is a setting that disables the entire /dev/urandom access:

    $CONFIGURATION = array(
        "no_udev_random" => TRUE,
        ...
    );

If you haven't given up on this, let me know if you try it.

Original comment by samuli.j...@gmail.com on 30 Oct 2013 at 11:52

[GoogleCodeExporter]

I tried your fix but it doesn't works for me ("no_udev_random" => TRUE is a 
part of my cinfiguration)

Error.log contains:

RESPONSE error {0:999, 1:Unexpected server error, 2:500} PHP error #2, 
is_readable(): open_basedir restriction in effect. File(/dev/urandom) is not 
within the allowed path(s):

Original comment by schnett...@gmail.com on 30 Oct 2013 at 12:16

[GoogleCodeExporter]

Oh crap, made a little typo, the value is used in a negative way.

Could you try with attached class, goes into 
"backend/vendor/phpass/PasswordHash.class" (or simply using the configuration 
value FALSE)

Original comment by samuli.j...@gmail.com on 30 Oct 2013 at 12:24

Attachments:

• PasswordHash.php

[GoogleCodeExporter]

A "False" let me login now! Thanks

Original comment by schnett...@gmail.com on 30 Oct 2013 at 12:46

[GoogleCodeExporter]

Actually he is right, i tried with both TRUE and FALSE, they work both ways 
when "user_auth" tables are completely cleared out. I don't think it should 
work that way either, even tho it's fine for me, i currently left the 
"no_udev_random" to FALSE.

Let's say us, windows users, or whoever else needs to disable the udev_random, 
does it make our configuration in some way weaker? or what exactly happens when 
the udev_random is disabled?

Original comment by Logic...@gmail.com on 30 Oct 2013 at 12:56

[GoogleCodeExporter]

As it's working now and hopefully disabling/enabling udev random option does 
not bring out any security shortcomings then i should mention that, guessing it 
is related with this issue: "email_login" => TRUE, does not work, it said 
username or password incorrect.

Also, it seems setting Debug in Mollify configuration to false, does not work, 
it's still in debug mode and writes all the stuff to PHP Error Log.

Why I'm saying it is that it seems to be related with the thing that no matter 
what you put in "no_udev_random", TRUE or FALSE, it still works. 

Just seems a bit weird.

Original comment by Logic...@gmail.com on 30 Oct 2013 at 1:09

[GoogleCodeExporter]

Just uploaded a new version 2.2.5 that has the option now turned the other way, 
the it was supposed. It also adds some debug logging to verify what it actually 
does. So if you update, be sure to turn the value to TRUE.

With this build, I tested following things:
- setting "no_udev_random" to FALSE (or not setting it all), logs verified it 
accessed /dev/urandom
- setting "no_udev_random" to TRUE, logs verified that it skipped this and used 
the fallback method
- setting "email_login" to FALSE did not let user login with email
- setting "email_login" to TRUE did let user login with email
- setting "debug" to FALSE did not generate debug log
- setting "debug" to TRUE did generate debug log

So if these settings don't work, make sure to check there is no syntax error in 
the configuration.php, and that you are not setting the values more than once. 
And note that all of these are backend settings (just in case you put some of 
these into client init).

For the question about whether not using /dev/urandom is less secure, I don't 
think there is much difference. The library itself had the fallback option to 
generate random bytes without /dev/urandom, it just did not handle it if the 
/dev/urandom was not accessible.

And sorry for all the hassle with this, I try to do my best to fix these 
(perhaps too fast), it's just impossible to know how different environments 
operate. The PHPass library really is widely suggested solution to be good and 
portable, I wonder this did not pop up in any of the discussions.

Original comment by samuli.j...@gmail.com on 30 Oct 2013 at 1:57

[GoogleCodeExporter]

Issue 485 has been merged into this issue.

Original comment by samuli.j...@gmail.com on 30 Oct 2013 at 1:57

[GoogleCodeExporter]

And oh yes, the random generator is not used on regular login, only when new 
passwords are hashed and stored. That's why changing the "no_udev_random" value 
does not have difference on regular login, only in following cases:

- user resets password
- user changes password
- after updating to 2.2.x and user logs in for the first time (when the hash is 
missing and it is generated automatically)

Original comment by samuli.j...@gmail.com on 30 Oct 2013 at 2:18

[GoogleCodeExporter]

I wiped the rows at "user_auth" table just to test it, since with previous 
version it added the hashes etc correctly. 
With "no_udev_random" TRUE or FALSE, i couldn't log in in both cases. PHP Error 
Log only says that there is that open_basedir restriction again. This time tho, 
no rows were deleted from the database, just nothing got added there.

Original comment by Logic...@gmail.com on 30 Oct 2013 at 2:32

[GoogleCodeExporter]

I should add that the error originates from:

\backend\vendor\phpass\PasswordHash.php:78   <- at line 78

Original comment by Logic...@gmail.com on 30 Oct 2013 at 2:38

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Ok, i replaced the entire PasswordHash.php FROM the OLD Mollify to the newest 
version of Mollify and now it DID let me log in and added correct data to 
database etc. Everything else was from the new Mollify installation so whatever 
is wrong, originates from PasswordHash.php

Original comment by Logic...@gmail.com on 30 Oct 2013 at 2:53

[GoogleCodeExporter]

Could I see your configuration.php, because this really does not make sense.

If you have the latest vendor/phpass/PasswordHash.class and debug => TRUE, you 
should have following thing in log every time hash is generated:

/dev/urandom: 0

or

/dev/urandom: 1

Where 0 means /dev/urandom is skipped. And if you have value 1, it is followed 
by log entry "Trying /dev/urandom".

And the line 78 you refer to, is exactly the line this setting skips when you 
have following line in configuration.php:

"no_udev_random" => TRUE,

note that it is not string but boolean (also in debug setting).

And if you want to "reset" user auth, you must set user_auth table to have "-" 
for both hash and salt. This is the indicator for "hash does not exist yet, use 
the old pw and create it the hash if the old pw matches".

Original comment by samuli.j...@gmail.com on 30 Oct 2013 at 3:06

[GoogleCodeExporter]

<?php
    $CONFIGURATION = array(
        "db" => array(
            "type" => "mysql",
            "host" => "127.0.0.1",
            "database" => "DATABASE",
            "user" => "USERNAME",
            "password" => "PASSWORD",
            "table_prefix" => "mollify_",
            "charset" => "utf8", // optional
            "no_udev_random" => TRUE,
        ),

        "settings" => array(
            "timezone" => "Europe/Tallinn",
            "debug" => TRUE,
            "enable_descriptions" => FALSE,
            "enable_folder_actions" => TRUE,
            "enable_descriptions" => FALSE,
            "enable_retrieve_url" => FALSE,
            "url_retriever_class" => "UrlRetriever.class.php",
            "convert_filenames" => "UTF-8",
            "enable_file_upload_progress" => TRUE,
            "host_public_address" => "URL",
            "enable_mail_notification" => TRUE,
            "mail_notificator_class" => "mail/MailNotificator.class.php",
            "mail_notification_from" => "EMAIL",
            "enable_zip_download" => TRUE,
            "zipper" => "ziparchive",
            "email_login" => TRUE,
            "enable_thumbnails" => TRUE,
        ),

        "plugins" => array(
            "LostPassword" => array(),
            "ItemDetails" => array(),
            "Archiver" => array(),
            "Share" => array(),
            "FileViewerEditor" => array(
                "viewers" => array(
                    "Image" => array("gif", "png", "jpg", "jpeg", "bmp"),
                    "Google" => array("pdf", "tiff", "doc"),
                    "TextFile" => array("txt", "js", "css", "xml", "html", "xhtml", "py", "c", "cpp", "as3", "sh", "java", "sql", "php"),
                    "JPlayer" => array("mp3", "ogg"),
                    "FlowPlayer" => array("mp4", "f4v"),
                    "Quicktime" => array("mov"),
                ),
                "previewers" => array(
                    "Image" => array("gif", "png", "jpg", "jpeg"),
                ),
                "editors" => array(
                    "TextFile" => array("txt", "js", "css", "xml", "html", "xhtml", "py", "c", "cpp", "as3", "sh", "java", "sql", "php"),
                ),
            ),
        ),
    );
?>

Original comment by Logic...@gmail.com on 30 Oct 2013 at 3:09

[GoogleCodeExporter]

Yes i had the "-" symbols in the database, i actually just used your script you 
suggested before @ mysql. 

The only thing i have in my PHP Error Log is (Debug is set to TRUE): 

MOLLIFY ERROR: PHP error #2, is_readable(): open_basedir restriction in 
effect...

But why does it work with the version before PasswordHash.php and not with the 
new one?

Original comment by Logic...@gmail.com on 30 Oct 2013 at 3:13

[GoogleCodeExporter]

No wonder, you do have wrong $CONFIGURATION structure.

It should be like this:

   $CONFIGURATION = array(
        "db" => array(
            "type" => "mysql",
            "host" => "127.0.0.1",
            "database" => "DATABASE",
            "user" => "USERNAME",
            "password" => "PASSWORD",
            "table_prefix" => "mollify_",
            "charset" => "utf8", // optional
        ),
        "no_udev_random" => TRUE,
        "timezone" => "Europe/Tallinn",
        "debug" => TRUE,
        "enable_descriptions" => FALSE,
        "enable_folder_actions" => TRUE,
        "enable_descriptions" => FALSE,
        "enable_retrieve_url" => FALSE,
        "url_retriever_class" => "UrlRetriever.class.php",
        "convert_filenames" => "UTF-8",
        "enable_file_upload_progress" => TRUE,
        "host_public_address" => "URL",
        "enable_mail_notification" => TRUE,
        "mail_notificator_class" => "mail/MailNotificator.class.php",
        "mail_notification_from" => "EMAIL",
        "enable_zip_download" => TRUE,
        "zipper" => "ziparchive",
        "email_login" => TRUE,
        "enable_thumbnails" => TRUE,

        "plugins" => array(
            "LostPassword" => array(),
            "ItemDetails" => array(),
            "Archiver" => array(),
and so on.

So there is no key "settings", the all settings are in the array itself. And 
you had the "no_udev_random" inside "db".

Original comment by samuli.j...@gmail.com on 30 Oct 2013 at 3:30

[GoogleCodeExporter]

Sorry for the late response, i was at work, but yes, it seems to be working 
correctly now. Sorry for causing all the hassle, at least something good came 
out of it by getting it compatible with Windows hosts.

Thank you, yet again.

Original comment by Logic...@gmail.com on 31 Oct 2013 at 6:36

[GoogleCodeExporter]

Sure, it was indeed good result, sorry that you had to be the "crash test 
dummy" with windows server. Have to add this FAQ etc.

Original comment by samuli.j...@gmail.com on 1 Nov 2013 at 8:08

• Changed state: Fixed

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Actually i don't mind at all, when I'm not working or anything i can do it 
freely, the only annoying part is that we have to communicate through this here 
and it's slow, some sort of IM would be better. So if you need to test 
something and i can avoid my silly mistakes, let me know.

Original comment by Logic...@gmail.com on 1 Nov 2013 at 2:10