WebLoginPE 1.3.0 Bug Reports

in webloginpe.class.php change

function ViewUserProfile($username)

to

function ViewUserProfile($username,$inputHandler)

and it works for me.

function ViewUserProfile($username,$inputHandler=array())

for utf-8 needers:
add this to SendMessageToUser

$EmailMessage->CharSet = $modx->config[’modx_charset’];

TXP uses UTF8 everywhere, so unless you’re sending email and need latin1, never use utf8_decode, because that converts it to latin1, which is wrong for 2 reasons:

* not all utf8 characters can be translated to latin1, resulting in question marks.

* you should not use latin1 on a page that has a utf8 charset. While utf8 is always valid latin1 (even if not readable), latin1 is not always valid utf8, especially if you characters with the high-bit set. Only the lower 7-bits of latin1 and utf8 are equal.

new PHPMailer();

        $varName->CharSet = $modx->config['modx_charset'];

I have a problem, after which more than 60 users is register on the site appears the following error:

Check your database, table web_users. Perhaps someone registered with an illegal character in his username like blank,ß,ä,ö,ü or something similar. I think I read something about a missing validation of usernames.

Array
(
[admin] => Array
(
[id] => 1
[username] => admin
[password] => xxxxxxx
[cachepwd] =>
[internalKey] => 1
[fullname] => admin
[role] => 0
[email_] => [email protected]
[phone] =>
[mobilephone] =>
[blocked] => 0
[blockeduntil] => 0
[blockedafter] => 0
[logincount] => 0
[lastlogin] => 1187902578
[thislogin] => 0
[failedlogincount] => 0
[sessionid] =>
[dob] => 0
[gender] => 0
[country] =>
[state] =>
[zip] =>
[fax] =>
[photo] =>
[comment] =>
)

[Ä20] =>

[username2] => Array
(
[id] => 3

...

I noticed a pretty bad bug today. It seems that the sorting options doesn’t respect a user’s wishes to "hide" a part of their profile, like their phone number. It outputs the number, instead of saying private.

Any idea how to fix this?

EDIT: Just to check, is it expected that in the sorting options, when you view a user’s profile, it shows up correctly, even if the customFields line isn’t in the snippet call? I was under the impression that you needed them for the fields to appear correctly.

Quote from: Soshite at Mar 16, 2008, 09:33 AM

I noticed a pretty bad bug today. It seems that the sorting options doesn’t respect a user’s wishes to "hide" a part of their profile, like their phone number. It outputs the number, instead of saying private.

Any idea how to fix this?

EDIT: Just to check, is it expected that in the sorting options, when you view a user’s profile, it shows up correctly, even if the customFields line isn’t in the snippet call? I was under the impression that you needed them for the fields to appear correctly.

@Soshite,

I haven’t had the opportunity to look into the sorting options yet, though I will make a point to do so. Is this the specific problem you are referring to? I’m not certain the above bug fixes will help unless you were experiencing the specific issues addressed.

Nah, that issue you quoted was something different. I was having issues where I was getting that "username already exists" when it didn’t, but it would create the user (even when the e-mail was bad / etc.)

That issue you quoted made it so, let’s say, the user had hid their phone number. In their profile, it worked as expected. But when you used a sorting option to view that field, it didn’t hide it.

//<?php - Used for highlighting only - do not copy

        // Original: ^[_a-z0-9-]+(\.[_a-z0-9-]+)*@[a-z0-9-]+(\.[a-z0-9-]+)*(\.[a-z]{2,4})$
        if (!eregi("^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,7}$", $Email)) // pixelchutes

Could you maybe post a working 1.3.pixelversion or maybe there can be some response from our Pirate Programmer on this case.
Does Scotty continue with this or can someone take it over to bring this app to his potential

when there is a version that has all fixes until now that I can go and test is, (I really want to test it and report back to someone that follows up).

Dimmy

Quote from: MadeMyDay at Nov 27, 2007, 12:39 AM

Check your database, table web_users. Perhaps someone registered with an illegal character in his username like blank,ß,ä,ö,ü or something similar. I think I read something about a missing validation of usernames.

This is definitely an open issue. For example, I can register using UTF-8 character encodings (e.g. Ä, §, etc) but then I cannot login and it also breaks the system! (E.g. ÄPPLE§)

//<?php // Used for highlighting only - Do Not Copy

// Check username for bullshit.
$illegals = array('.' , ',' , '/' , '\\' , '`' , ';' , '[' ,  ']' , '-', "'", '*', '&', '^', '%', '$', '#', '@', '!', '~', '+', '(', ')', '|', '{', '}', '<', '>', '?', ':', '"', '='); 
$badUsername = str_replace($illegals, '', $username);
if (strlen($badUsername) !== strlen($username))

//<?php // Used for highlighting only - Do Not Copy

// Check username for bullshit.
if( strspn($_POST['username'],'"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789_') != strlen($_POST['username']) ) // pixelchutes