News:

SMF 2.1.6 has been released! Take it for a spin! Read more.

Main Menu

Language determination

Started by Elmacik, July 21, 2009, 07:48:26 AM

Previous topic - Next topic

Elmacik

SMF Version: All versions of SMF 1.x and SMF 2.x

If the language preference is changed through through URL like:

http://www.example.com/index.php?language=turkish

SMF will recognize your selection and will update the value of $context['user']['language'] with your preference. I don't know if it is intended but SMF fills this variable with whatever you type for language in query string.

For example if you browse the forum as:
index.php?language=nonsense

Your user language will be set to "nonsense" for that session and will be recognized as so. The forum will continue to work normally if there is no language like that; but it also prevents you getting a reliable user language preference.

Example: I have a multilingual homepage that fetches some SSI content from SMF. I just show the page in SMF's language. For example if the user prefers English in SMF, the homepage shows in English. There are also links to change the site language. It is important because not only the menus change, but also the content changes.

Of course I can check if they typed a valid language name (or clicked a correct link) in my homepage; but it won't remember the correct value. Because SMF keeps the language value in $_SESSION and in $context. (I shouldn't be editing SMF files for my homepage to function correctly, huh?)

This situation causes conflicts between SMF and the homepage.

Solution: SMF should check the language validity. If it is invalid, SMF shouldn't change the value of the user language variables. (There are some varying.) This will help preventing malfunctions in integrations with other scripts and the SMF modifications which uses language preference of the users/guests.
Home of Elmacik

karlbenson

For SMF 2.0 RC2 when it is released, we have already made several changes including checking that its a valid language.

I don't think we intend to back-port the changes to the 1.1.x branch since its mainly only getting security fixes.
Whilst setting a language to nonsense isn't a good idea. There are security checks in place to ensure its not exploitable.

Marking as resolved.

Elmacik

#2
I didn't even mention about "exploiting" and I of course know setting the language to nonsense is not a good idea. If you've read my message, you'll see I'm talking about the integrations and the modifications to SMF.

Furthermore, you always have to think of the probabilities that the members/guests will cause. This is not a security issue, this is an issue that will cause the content to be ambiguous.

Bugs are not always related to "security" and since you already thought to implement it to SMF 2.0, then you've already proven that this functionality is necessary. If setting the language to nonsense isn't a good idea really, then you could have left the functionality as it is; why did you feel to change it in SMF 2.0? :)

Edit: I set the $_SESSION['language'] value to what I need in the homepage. Then when someone clicks to "forum" link, SMF recognizes the $_SESSION['language'] but it uses this variable only in some places. So, forum mistakenly acts half English and half other language; and this is obviously a bug. For example now in my forum, the language is Turkish in contrast to value of $_SESSION['language']. However, the images are shown from English directory referencing the value of $_SESSION['language'].

Additionally, SSI correctly shows the language in English (it remembers my selection) but the forum in the same directory reverts back to the other language although "English" is selected in my profile. This causes forum to be half English and half Turkish.
Home of Elmacik

Elmacik

Hmm.. You haven't added even to SMF 2.x branch yet. Even this site is affected.

See here: http://www.simplemachines.org/community/index.php?board=19.0;language=qwerty

As you'll see, "new.gif" icons are tried to be fetched from a non-existing language directory "qwerty". And this is absolutely a bug. It affects both SMF 1.x and SMF 2.x
Home of Elmacik

Aleksi "Lex" Kilpinen

This site is not running 2.0 RC2.

Quote from: regularexpression on July 21, 2009, 02:15:42 PM
For SMF 2.0 RC2 when it is released, we have already made several changes including checking that its a valid language.
Slava
Ukraini!
"Before you allow people access to your forum, especially in an administrative position, you must be aware that that person can seriously damage your forum. Therefore, you should only allow people that you trust, implicitly, to have such access." -Douglas

How you can help SMF

karlbenson

Indeed we're still using 2.0 RC1.2 on this site at the moment.
But I can guarantee that this bug is fixed in our svn version (2.0 rc2 for when it is released).

Like I said above though, although it is a bug that affects 1.1.x it won't be backported.

Elmacik

And?

Quote from: Elmacik on July 22, 2009, 08:38:14 AM
Hmm.. You haven't added even to SMF 2.x branch yet. Even this site is affected.

See here: http://www.simplemachines.org/community/index.php?board=19.0;language=qwerty

As you'll see, "new.gif" icons are tried to be fetched from a non-existing language directory "qwerty". And this is absolutely a bug. It affects both SMF 1.x and SMF 2.x
Home of Elmacik

Aleksi "Lex" Kilpinen

I can see this effecting both 1.1 and 2.0, just like you said - but just like regularexpression said, this has already been fixed for an upcoming version - not released yet.
Slava
Ukraini!
"Before you allow people access to your forum, especially in an administrative position, you must be aware that that person can seriously damage your forum. Therefore, you should only allow people that you trust, implicitly, to have such access." -Douglas

How you can help SMF

Advertisement: