Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot change profile photo #6914

Closed
lapo-luchini opened this issue Mar 21, 2019 · 11 comments

Comments

Projects
None yet
3 participants
@lapo-luchini
Copy link

commented Mar 21, 2019

Expected behavior

Biong able to change profile photo.

Actual behavior

«The form security token was incorrect. This probably happened because the form has not been submitted within 3 hours.»

Steps to reproduce the problem

  1. Upload profile photo, or select existing one.
  2. Crop/choose
  3. press «Done editing»
  4. «The form security token was incorrect. This probably happened because the form has not been submitted within 3 hours.»
  5. check list of photos: one more copy is present now (identical copy, whatever crop factor was chosen)

Friendica version you encountered the problem

see example.com/friendica on your Friendica node for the version information.
This is Friendica, version 2019.01 […]. The database version is 1293, the post update version is 1281.

Friendica source (git, zip)

git 95a16c8

PHP version

7.3.3

SQL version

MySQL 5.7.24

@MrPetovan

This comment has been minimized.

Copy link
Collaborator

commented Mar 22, 2019

Hi @lapo-luchini and thank you for your report. Are you able to consistently reproduce this? We're about to release the next stable version 2019.03, will you be ableto upgrade to it and report if the problem still persists?

@tobiasd

This comment has been minimized.

Copy link
Collaborator

commented Mar 22, 2019

I have tried to reproduce this using Firefox and Vivaldi with vier and frio themes, but could not.

Do you have access to the server? It could be a mismatch of the time settings between the server and your computer, so that the time window which is scheduled for working on the profile picture runs out really quick.

@lapo-luchini

This comment has been minimized.

Copy link
Author

commented Mar 22, 2019

Hi, I am root of the server (I installed it myself) and can consistently reproduce that.
Please notice that posting messages and comments gives me no problem, uploading images neither, only changing my profile seems to be affected.
I will be git pull-ing as soon as a new master is available, sure.

@lapo-luchini

This comment has been minimized.

Copy link
Author

commented Mar 22, 2019

(I am also willing to try patches, adding debug code or whatever can help)

@lapo-luchini

This comment has been minimized.

Copy link
Author

commented Mar 23, 2019

Still happens on 854cc3e, how can further debug?

@lapo-luchini

This comment has been minimized.

Copy link
Author

commented Mar 23, 2019

It could be a mismatch of the time settings between the server and your computer

Mh, both are time sync'ed, shouldn't be more than a few secs.

I found a timezone mismatch between the MySQL and the PHP jails:

mysql# date
Sat Mar 23 17:32:18 UTC 2019
php73# date
Sat Mar 23 18:32:30 CET 2019

I fixed that (which still shouldn't be a problem, if times are correctly compared), but nothing changed.

@lapo-luchini

This comment has been minimized.

Copy link
Author

commented Mar 24, 2019

$sec_hash = hash('whirlpool', $a->user['guid'] . $a->user['prvkey'] . session_id() . $timestamp . $typename);

session_id() seems to be the culprit, it changed between getFormSecurityToken and checkFormSecurityToken.

Both values can be found in MySQL table sessions, the oldest one contains:

last_login_date|s:19:"2019-03-24 13:47:06"

the latter one contains

last_login_date|s:19:"2019-03-24 13:47:09"

it seems that I get logged in on each page change.

I created a sample page with:

<?php
session_start();
$_SESSION['test'] = $_SESSION['test'] + 1;
echo '[' . session_id() . ']';
echo '[' . $_SESSION['test'] . ']';
session_end();
?>

and the SID is always the same and the test counter increases one by one (and I can find the serialized value in the file session storage), so PHP's internal session management works fine. Seems to be Friendica-specific.

@lapo-luchini

This comment has been minimized.

Copy link
Author

commented Mar 24, 2019

Found it! The varnish cache was configured to ignore cookies for some static resources, but thanks to rewrite in the case of Friendica those static resources are not static at all, this forced a re-generation of the session_id() and, thus, the problem.
Having fixed that, I still get a warning on each page reload, on a link that didn't have that problem (I solved), I wonder if this is correct:
Session read (no data): rbamsgqgv0pg4sfdn387krf88f from /manifest
(I added a log after DatabaseSessionHandler::read to show the URL of the offending page)
This still happens, and generates a new session_id (and entry in the DB) each time, but I don't understand why.

@lapo-luchini

This comment has been minimized.

Copy link
Author

commented Mar 24, 2019

I see with Chrome Inspector that /manifest request doesn't have a Cookie value to start with, so I guess that "extra session" is "normal" (while spurious). I'm closing this bug.

@lapo-luchini

This comment has been minimized.

Copy link
Author

commented Mar 24, 2019

(I created #6927 for that.)

@MrPetovan

This comment has been minimized.

Copy link
Collaborator

commented Mar 24, 2019

Nice work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.