preview.png has disappered (General)

by Ecker, Saturday, June 30, 2018, 00:32 (85 days ago)

I just noticed the ajax_preview.png has disappeared, I have two forums on the same site the main forum is where it disappeared from, I check the ((Admin ajax_preview is set to (1)

Im really not sure what to do.

Image of the forum, where the preview balloon

by Ecker, Saturday, June 30, 2018, 03:35 (85 days ago) @ Ecker

balloon just disappeared.

there is no more preview balloon

[image]

Avatar

The preview balloon is, where it was all the time

by Auge ⌂ @, Saturday, June 30, 2018, 17:35 (84 days ago) @ Ecker

Hello

balloon just disappeared.

there is no more preview balloon

Of course, there is!

Please check the directory themes/default/images (or whatever theme you use) for the presence of ajax_preview.png. As you can see, following the link above, the actual version 2.4.12 contains the image.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

The preview balloon is, where it was all the time

by Ecker, Sunday, July 01, 2018, 03:10 (84 days ago) @ Auge

I did checked the image file and the ajax_preview.png image is in the directory,

I also took the default directory from the Off Topic forum, that is the forum that still has the balloon present on the forum,

I renamed the default directory to default2 from the forum I'm having issues with then took the default directory from the off topic forum, the forum that still has the balloon present and uploaded to the troubled forum, after uploading the directory the balloon is still a no show. its hiding somewhere,

what file directs the forum to show the balloon. possible issues there.
also if I update the forum that would most likely fix the issue right now I'm using 2.4.9

preview.png has disappered---updated and figured out-

by Ecker, Sunday, July 01, 2018, 22:27 (83 days ago) @ Ecker

Not sure if it was intended but when post have been locked the preview balloon disappears.

I would think the preview should be available for all post even the locked post.

Avatar

preview.png has disappered, updated and figured out

by Auge ⌂ @, Monday, July 02, 2018, 08:14 (82 days ago) @ Ecker

Hello

Not sure if it was intended but when post have been locked the preview balloon disappears.

I can confirm this (partially). The first thread that is marked as locked, I found, is this one. Please take notice, that only the opening message is locked. One is able to answer to the replies.

The image below shows the thread tree, top in the main view (threaded, same behaviour in the table view) and bottom in the view of a single entry. As you can see, the "balloon" is missed for the opening message in the main view and the replies (which are open for answers) got their "balloons". But in the entry view, below the message, the locked opening message has a "balloon".

I don't know the criteria to set the "balloon" or not for every case. I hope, that Milo is able to tell us something about it.

[image]

I would think the preview should be available for all post even the locked post.

ACK

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

preview.png has disappered, updated and figured out

by Milo ⌂, Monday, July 02, 2018, 09:22 (82 days ago) @ Auge

Hej,

I take a very short look to the sources. I guess, the problem is the list of accepted css-classes in line L1396:

["ap", "reply", "thread", "replynew", "threadnew", "thread-sticky", "threadnew-sticky", "reply-search", "thread-search"]

The css class of a link of a locked posting is thread-locked. I believe, we just have to extend the class list by (at least) thread-locked.


/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

preview.png has disappered, updated and figured out

by Auge ⌂ @, Monday, July 02, 2018, 09:42 (82 days ago) @ Milo

Hello

I take a very short look to the sources. I guess, the problem is the list of accepted css-classes in line L1396:

["ap", "reply", "thread", "replynew", "threadnew", "thread-sticky", "threadnew-sticky", "reply-search", "thread-search"]

The css class of a link of a locked posting is thread-locked. I believe, we just have to extend the class list by (at least) thread-locked.

Sounds reasonable. It fits my observation of "balloon" not showing up in the main view but in the thread tree of the entry page, where the opening entry is not marked as locked.

[edit]I closed the development thread for the version 2.4 to compare it with the behaviour of the thread from my last entry (only opening entry is locked) and reloaded the main page. The "balloon" disappears in the main view from the opening message but not from the replies which are also locked. You are right, it's the class name of the opening messages HTML-list-item.[/edit]

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

preview.png has disappered, updated and figured out

by Milo ⌂, Monday, July 02, 2018, 19:09 (82 days ago) @ Auge

Hi,

I update this forum to version 2.4.12 and add the missing css-class to the main.js/main.min.js. Now, the "balloon" is shown for locked threads. I added the code to our git.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Tags:
javascript, preview, 2.4.13

Avatar

preview.png has disappered, updated and figured out

by Auge ⌂ @, Tuesday, July 03, 2018, 07:27 (81 days ago) @ Milo

Hello

I update this forum to version 2.4.12 and add the missing css-class to the main.js/main.min.js. Now, the "balloon" is shown for locked threads. I added the code to our git.

Thank you. I will alter the input names for the registration- and login-forms today. Are there further forms, where we need to alter the names?

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

preview.png has disappered, updated and figured out

by Milo ⌂, Tuesday, July 03, 2018, 07:59 (81 days ago) @ Auge

Hi,

I will alter the input names for the registration- and login-forms today.

As far as I know, the login form doesn't us honey pots.

Are there further forms, where we need to alter the names?

The posting-form (at least for unregistered users) should be reworked, too.

What do you think about hashing the field names? In template, we can use {$string|md5} and in PHP, we just use md5($string). MD5 is just an example (we can use every crypt/hash function) but MD5 is supported by smarty _and_ PHP. The benefit is, that the field names are still readable in the source code, i.e. $_POST[md5("email")] is more readable than $_POST['dkjhfhf324rkj'].

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

preview.png has disappered, updated and figured out

by Auge ⌂ @, Tuesday, July 03, 2018, 08:28 (81 days ago) @ Milo

Hello

I will alter the input names for the registration- and login-forms today.


As far as I know, the login form doesn't us honey pots.

I will look into it. Thank you for the hint for now.

Are there further forms, where we need to alter the names?


The posting-form (at least for unregistered users) should be reworked, too.

Yes, you are right.

What do you think about hashing the field names? In template, we can use {$string|md5} and in PHP, we just use md5($string). MD5 is just an example (we can use every crypt/hash function) but MD5 is supported by smarty _and_ PHP. The benefit is, that the field names are still readable in the source code, i.e. $_POST[md5("email")] is more readable than $_POST['dkjhfhf324rkj'].

In general this would be a nice idea because it creates adequate shuffled strings. But this way we would hashing the same strings with the same results on every request again and again. Nothing I like. To hashing them once (today) and write the hashes hardcoded into the templates and scripts would prevent the hashing on every request but would also lower the readability of the code. Additionally the hashed but hardcoded field names are IMHO only an interim solution. IMHO its preferable to have different shuffled names on every request.

What's with generating the hash from the field name (for the readability of the code) and the CSRF-token that gets generated for every single of the affected forms? The token is known in the session, the token is known to the form and the smarty engine and it's also known to the script, that evaluates the form content.

# before generating the form (PHP code, can also be done with the Smarty engine)
$smarty->assign('new_user_name', md5("new_user_name" . $_SESSION['csrf_token']));
#after returning the forms input
$new_user_name = $_POST[md5("new_user_name" . $_SESSION['csrf_token'])];

Example works with MD5, but it can also be done with another algorithm.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

preview.png has disappered, updated and figured out

by Milo ⌂, Tuesday, July 03, 2018, 08:48 (81 days ago) @ Auge

Hi,

In general this would be a nice idea because it creates adequate shuffled strings. But this way we would hashing the same strings with the same results on every request again and again.

Of course but the again and again only applies on pages that contain a forms. If people just read the threads or postings, nothing will generated.

What's with generating the hash from the field name (for the readability of the code) and the CSRF-token that gets generated for every single of the affected forms?

This sounds nicely and we can remove the hidden field of the CSRF-token because each field name is like a CSRF.

# before generating the form (PHP code, can also be done with the Smarty engine)
$smarty->assign('new_user_name', md5("new_user_name" . $_SESSION['csrf_token']));

The overhead of this solution is, that we have to define variables for each field.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

preview.png has disappered, updated and figured out

by Auge ⌂ @, Tuesday, July 03, 2018, 10:11 (81 days ago) @ Milo

Hello

In general this would be a nice idea because it creates adequate shuffled strings. But this way we would hashing the same strings with the same results on every request again and again.


Of course but the again and again only applies on pages that contain a forms. If people just read the threads or postings, nothing will generated.

Yes, that's correct. Where hashing gets not performed, it got not performed. Even on the registration page, this should not be problematic In the posting form it can has a performance impact if the forum is well frequented. In that case it's (for me) much more reasonable to generate new, different hashes very time instead the same hash again and again.

What's with generating the hash from the field name (for the readability of the code) and the CSRF-token that gets generated for every single of the affected forms?


This sounds nicely and we can remove the hidden field of the CSRF-token because each field name is like a CSRF.

Would this make the token field really obsolete?

# before generating the form (PHP code, can also be done with the Smarty engine)
$smarty->assign('new_user_name', md5("new_user_name" . $_SESSION['csrf_token']));


The overhead of this solution is, that we have to define variables for each field.

Yes, we have to do this in PHP or in Smarty and in Smarty it seems to be a bit shady. All I found about string concatenation in Smarty is very old (forum entries from 2001 to 2003) as well as a bit complicated. I think it's the easiest way to generate the field names in PHP and to transfer it to the Smarty templates afterwards.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

preview.png has disappered, updated and figured out

by Milo ⌂, Tuesday, July 03, 2018, 12:28 (81 days ago) @ Auge

Hi Auge,

Would this make the token field really obsolete?

Yes, because only the server knows the salt (i.e. CSRF) token. It is not possible to generate the names of the form fields without having knowledge of the token (with some probability).

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

preview.png has disappered, updated and figured out

by Auge ⌂ @, Tuesday, July 03, 2018, 14:40 (81 days ago) @ Auge

Hello

I will alter the input names for the registration- and login-forms today.

@Milo: I've altered the registration form and tested it in my forum. Strange! I had to remove the form data, stored in my browser, to be able to registrate anew. Even with hashed form-element-names the browser filled out the repeat-email-field. …

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

preview.png has disappered, updated and figured out

by Milo ⌂, Tuesday, July 03, 2018, 20:54 (81 days ago) @ Auge

Hi,

Even with hashed form-element-names the browser filled out the repeat-email-field. …

Yes, because the names are not the indicators: https://stackoverflow.com/questions/10738090/why-firefox-autocomplete-even-with-different-input-name.

For testing: Can you change the order of the text fields?

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

preview.png has disappered, updated and figured out

by Auge ⌂ @, Wednesday, July 04, 2018, 10:02 (80 days ago) @ Milo

Hello

Even with hashed form-element-names the browser filled out the repeat-email-field. …


Yes, because the names are not the indicators: https://stackoverflow.com/questions/10738090/why-firefox-autocomplete-even-with-different-input-name.

Thank you for the linked explanation. Following quotes from there.

"If form contains more than 3 password fields, the autofill function ignores that form."

Not our case. Would be a really dirty workaround but I do not like it.

"After 1 to 3 password fields are found, the browser looks for login field. The browser does a backward search starting from first password field and assumes that the login field is the first found field of the type text or email or url or tel or number."

That seems to be the breaking point of our registration form. The field above the two password fields is the field #repeat_email. Also it is the field, that gets filled with a user name I often use and so it prevents me to registrate a new user (normally for testing purposes).

Both, the workaround with the hidden fields between the username and the password fields as a honeypot for Firefox as well as the disabled input (<input type="text" disabled="disabled" style="display:none">) between the username and the password fields that stops Firefox from searching (if I understood it correct) are more or less dirty tricks. Setting the type of our spam protection honeypot fields to a value different from email, url, tel or number is no solution because the default template generates a XHTML-1.0-document, where these types are unknown and invalid. Even when we would use a HTML-5-based theme per default, Firefox searches for every textual input type with exception of password and search (and number as non-text-type).

For testing: Can you change the order of the text fields?

I will fiddle with the field order later today. Today is a World-Cup-free-day so I'll have free time.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

preview.png has disappered, updated and figured out

by Auge ⌂ @, Wednesday, July 04, 2018, 17:03 (80 days ago) @ Auge

Hello

For testing: Can you change the order of the text fields?


I will fiddle with the field order later today. Today is a World-Cup-free-day so I'll have free time.


Meanwhile I fiddled around and succeeded with the following order (with their old names).

1. hidden "mode"
2. hidden "csrf_token"
3. text "new_user_name"
4. password "reg_pw"
5. password "reg_pw_conf"
6. text "phone"
7. text "new_user_email"
8. text "repeat_email"

The field for the username got filled automatically but this is not a problem because one sees and can handle it.

@Milo: Do you see any problems with leaving it in this order?

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

preview.png has disappered, updated and figured out

by Milo ⌂, Wednesday, July 04, 2018, 17:19 (80 days ago) @ Auge

Hi,

@Milo: Do you see any problems with leaving it in this order?

No. If it works, change it. ;-) I don't have Firefox installed.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

preview.png has disappered, updated and figured out

by Milo ⌂, Wednesday, July 04, 2018, 17:36 (80 days ago) @ Auge

Hi,

1. hidden "mode"
2. hidden "csrf_token"
3. text "new_user_name"
4. password "reg_pw"
5. password "reg_pw_conf"
6. text "phone"
7. text "new_user_email"
8. text "repeat_email"

@Milo: Do you see any problems with leaving it in this order?

I take a look to the FF function. The relevant code should be:

        // Locate the username field in the form by searching backwards
        // from the first passwordfield, assume the first text field is the
        // username. We might not find a username field if the user is
        // already logged in to the site.
        for (var i = pwFields[0].index - 1; i >= 0; i--) {
            var element = form.elements[i];
            var fieldType = (element.hasAttribute("type") ?
                             element.getAttribute("type").toLowerCase() :
                             element.type);
            if (fieldType == "text"  ||
                fieldType == "email" ||
                fieldType == "url"   ||
                fieldType == "tel"   ||
                fieldType == "number") {
                usernameField = element;
                break;
            }
        }

FF is searching backwards, thus, your suggestion should work fine.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

RSS Feed of thread
powered by my little forum