Flyspray :: https://bugs.flyspray.org/ Flyspray :: Flyspray - The bug killer!: Recently opened tasks 2019-02-05T02:50:28Z FS#2543: spam https://bugs.flyspray.org/index.php?do=details&task_id=2543 2019-02-05T02:50:28Z anonymous spam spam

]]>
FS#2536: store session in Flyspray database https://bugs.flyspray.org/index.php?do=details&task_id=2536 2019-01-21T06:44:41Z peterdd Currently the sessions are stored by the webservers default settings. Having this sessions under control by Flyspray by storing it in the database has following advantages: Allows handling of all sessions of a user by Flyspray. Providing a session management for each user. The user can see on which devices he is currently logged in and could also force a logout on selective devices. A forced logoff of all or some user sessions is easy implementable for admins. Statistics about how many users and who is logged in. (user status: hide always, online, offline, do not disturb, ..) Could make onpage-notifications easier to implement. .. ? Disadvantages: A potential unknown security bug in Flyspray that could lead to reading a session db table could leak informations like who is currently online/active and make further attacks more focused or makes session takeover easier. .. ? Currently the sessions are stored by the webservers default settings.

Having this sessions under control by Flyspray by storing it in the database has following advantages:

  1. Allows handling of all sessions of a user by Flyspray.
  2. Providing a session management for each user. The user can see on which devices he is currently logged in and could also force a logout on selective devices.
  3. A forced logoff of all or some user sessions is easy implementable for admins.
  4. Statistics about how many users and who is logged in. (user status: hide always, online, offline, do not disturb, ..)
  5. Could make onpage-notifications easier to implement.
  6. .. ?

Disadvantages:

  1. A potential unknown security bug in Flyspray that could lead to reading a session db table could leak informations like who is currently online/active and make further attacks more focused or makes session takeover easier.
  2. .. ?
]]>
FS#2535: new optional Flyspray setting: add new users automatically to a project user group https://bugs.flyspray.org/index.php?do=details&task_id=2535 2019-01-16T17:28:12Z peterdd When a Flyspray installation allows user self registration and has public but also more private projects, this feature could make the required configuration more clear: In this case, keep the number of global user groups as low as possible and the global user group for basic or just registered users has only the ‘can login’ permission and nothing more.Because that only would be useless for new registered users, adding them also to a basic user group of a public project could be useful. So my suggestion is: A new optional global setting: Something like ‘default project user group’ (store 2 values: a project_id and a group_id). Validity of that setting must be checked during any user registration, so that project must exists now and at later time as also that project user group within that project. (’Checks’ of admin prefs) So it would be like this for a new registered userA: userA is in a basic default global user group: only login permission to handle his account registration (login, logout, user preferences, password forgotten) userA is in project X default user group: some basic permissions you want allow for every (new) registered user in project X project Y: all ‘allow anyone ...’-settings are unchecked, userA not in any user group of project Y The setting is probably best put below the ‘Default global group for new users’ setting in the global admin prefs tab #userregistration as Either: A dropdown list with all public projects with an existing user group and dependend on the selection the available basic project groups are loaded by ajax as a select list too. Or: Only one dropdown list that contains a list of public projects with possible project user groups. Would not require extra ajax calls and is maybe enough because we could exclude project groups that have project manager permission or such configuration nobody would allow new registered users. no default project user group public projectA - simple user groupA1 public projectA - simple user groupA2 public projectB - simple user groupB public projectC - simple user groupC This idea could be enhanced further (put the new user to multiple public projects when he registers or let user choose from public allowed projects during registration process), but lets start simple. When a Flyspray installation allows user self registration and has public but also more private projects, this feature could make the required configuration more clear:

In this case, keep the number of global user groups as low as possible and the global user group for basic or just registered users has only the ‘can login’ permission and nothing more.
Because that only would be useless for new registered users, adding them also to a basic user group of a public project could be useful.

So my suggestion is:

A new optional global setting: Something like ‘default project user group’ (store 2 values: a project_id and a group_id). Validity of that setting must be checked during any user registration, so that project must exists now and at later time as also that project user group within that project. (’Checks’ of admin prefs)

So it would be like this for a new registered userA:

  1. userA is in a basic default global user group: only login permission to handle his account registration (login, logout, user preferences, password forgotten)
  2. userA is in project X default user group: some basic permissions you want allow for every (new) registered user in project X
  3. project Y: all ‘allow anyone ...’-settings are unchecked, userA not in any user group of project Y

The setting is probably best put below the ‘Default global group for new users’ setting in the global admin prefs tab #userregistration as

Either: A dropdown list with all public projects with an existing user group and dependend on the selection the available basic project groups are loaded by ajax as a select list too.

Or: Only one dropdown list that contains a list of public projects with possible project user groups. Would not require extra ajax calls and is maybe enough because we could exclude project groups that have project manager permission or such configuration nobody would allow new registered users.

no default project user group
public projectA - simple user groupA1
public projectA - simple user groupA2
public projectB - simple user groupB
public projectC - simple user groupC

This idea could be enhanced further (put the new user to multiple public projects when he registers or let user choose from public allowed projects during registration process), but lets start simple.

]]>
FS#2534: Private projects https://bugs.flyspray.org/index.php?do=details&task_id=2534 2019-01-16T11:51:57Z Trent Gamblin I would like to restrict certain projects from view from normal users (Basic group.) I couldn’t find out a way to do it. I could restrict them from viewing tasks, which is good, but it would be nice to hide the project entirely from the Overview screen. I would like to restrict certain projects from view from normal users (Basic group.) I couldn’t find out a way to do it. I could restrict them from viewing tasks, which is good, but it would be nice to hide the project entirely from the Overview screen.

]]>
FS#2532: spaces before or after a single word search gives too many results https://bugs.flyspray.org/index.php?do=details&task_id=2532 2019-01-11T07:13:15Z peterdd Spaces before or after a task search string gives too many results in the tasklist. Example search strings: test (space after word test) test test (space after word test) Found this on bugs.archlinux.org, but also current 1.0-rc7 has this problem. Spaces before or after a task search string gives too many results in the tasklist.

Example search strings:

test (space after word test)
 test
 test (space after word test)

Found this on bugs.archlinux.org, but also current 1.0-rc7 has this problem.

]]>
FS#2531: detect usage of translation keywords https://bugs.flyspray.org/index.php?do=details&task_id=2531 2019-01-10T23:44:30Z peterdd Some translation keywords of Flyspray are used at more than one code location. To help translators doing the correct translations, it would help to show in what context a translation keyword is used.Especially when a keyword is used more than once. As we have our own translation helper integrated into Flyspray, we could show a ‘translation keyword usage counter’ there and maybe show on request in which filea translation keyword is used. It would also help to identify ‘abandoned’ translation keywords that are not used anymore by Flyspray source. I think we can use a regular expression and scan the whole Flyspray source for that.(and maybe database entries if there are places that have translation keywords stored - I don’t think so, but better check that too first than forget that case) The regular expression should match that examples case insensitive for the translation keyword report: L('report' L("report" eL('report' eL("report" but also ugly cases like l( 'report' or El ( "report" case insensitive. But not for example createURL('report' Some translation keywords of Flyspray are used at more than one code location.

To help translators doing the correct translations, it would help to show in what context a translation keyword is used.
Especially when a keyword is used more than once.

As we have our own translation helper integrated into Flyspray, we could show a ‘translation keyword usage counter’ there and maybe show on request in which file
a translation keyword is used.

It would also help to identify ‘abandoned’ translation keywords that are not used anymore by Flyspray source.

I think we can use a regular expression and scan the whole Flyspray source for that.
(and maybe database entries if there are places that have translation keywords stored - I don’t think so, but better check that too first than forget that case)

The regular expression should match that examples case insensitive for the translation keyword report:

L('report' 
L("report"
eL('report'
eL("report"

but also ugly cases like
l(    'report'
or 
El ( "report"

case insensitive.

But not for example

createURL('report'
]]>
FS#2528: New user registration doesn't check for duplicate usernames https://bugs.flyspray.org/index.php?do=details&task_id=2528 2019-01-07T09:24:27Z Stefan Steps done to create the problem:Visit https://bugs.flyspray.org/index.php?do=register in a private browser window (so you are logged out) Put in an already taken username (e.g. Stefan or Stefan2) Expected behavior:Username gets red and a note appears that username already is taken Experienced behavior:Username gets green and registration of a new user proceeds with sending a notification mail with confirmation code.After putting in the confirmation code in provided page, user gets presented a “username is already taken, choose another” (where?) message, and has to re-start registration process from beginning and hopefully this time choose a not taken name. Steps done to create the problem:
Visit https://bugs.flyspray.org/index.php?do=register in a private browser window (so you are logged out)

Put in an already taken username (e.g. Stefan or Stefan2)

Expected behavior:
Username gets red and a note appears that username already is taken

Experienced behavior:
Username gets green and registration of a new user proceeds with sending a notification mail with confirmation code.
After putting in the confirmation code in provided page, user gets presented a “username is already taken, choose another” (where?) message, and has to re-start registration process from beginning and hopefully this time choose a not taken name.

]]>
FS#2527: Database Check »Your mysql supports full utf-8 since 5.5.3.« always shown https://bugs.flyspray.org/index.php?do=details&task_id=2527 2019-01-05T14:24:02Z Stefan Steps done to create the problem:Access /index.php?do=admin&area=checks with a MySQL Version >= 5.5.3 Expected behavior:Flyspray tests for character set and displays »Your mysql supports full utf-8 since 5.5.3. You are using x.x.x and flyspray tables could be upgraded.« when database schema or one table isn’t set to utf8mb4 character set. Experienced behavior:Flyspray always shows this note, even though character set is correct. As far as I can tell from the source, a query gets executed to the database (and if I do that manually the result is “utf8mb4, utf8mb4_unicode_ci” for my database), but the result doesn’t get checket, the note is always shown (line 123) Steps done to create the problem:
Access /index.php?do=admin&area=checks with a MySQL Version >= 5.5.3

Expected behavior:
Flyspray tests for character set and displays »Your mysql supports full utf-8 since 5.5.3. You are using x.x.x and flyspray tables could be upgraded.« when database schema or one table isn’t set to utf8mb4 character set.

Experienced behavior:
Flyspray always shows this note, even though character set is correct.

As far as I can tell from the source, a query gets executed to the database (and if I do that manually the result is “utf8mb4, utf8mb4_unicode_ci” for my database), but the result doesn’t get checket, the note is always shown (line 123)

]]>
FS#2525: Error Ldap authorization after udgrade https://bugs.flyspray.org/index.php?do=details&task_id=2525 2018-11-27T23:29:07Z Voitynskyi Andriy Hi.I am upgrading Flyspray 1.0-rc6 to Flyspray 1.0-rc7 and after that, users cannot authorizations in flyspray.In my configuration used ldap authorization.(Error #7: Login failed password incorrect!) Hi.
I am upgrading Flyspray 1.0-rc6 to Flyspray 1.0-rc7 and after that, users cannot authorizations in flyspray.
In my configuration used ldap authorization.(Error #7: Login failed password incorrect!)

]]>
FS#2524: SMTP Mailer doesn't accept custom ports https://bugs.flyspray.org/index.php?do=details&task_id=2524 2018-11-27T23:29:49Z Christopher Did you installed an official release or did you used an inoffical docker?!YeahMySQL 8.0.12, 7.2.9 on debian buster Steps done to create the problem:Enter server:port at Mail-Settings Expected behavior:smtp.example.com:customport would make use of the custom port Experienced behavior:TLS Errors if ($fs->prefs['email_tls']) { $swiftconn = Swift_SmtpTransport::newInstance($fs->prefs['smtp_server'], 587, 'tls'); } else if ($fs->prefs['email_ssl']) { $swiftconn = Swift_SmtpTransport::newInstance($fs->prefs['smtp_server'], 465, 'ssl'); } else { $swiftconn = Swift_SmtpTransport::newInstance($fs->prefs['smtp_server']); } Should be changed to $someTemporaryVariable = explode(':',$fs->prefs['smtp_server']); if ($fs->prefs['email_tls']) { $swiftconn = Swift_SmtpTransport::newInstance($someTemporaryVariable[0], $someTemporaryVariable[1] || 587, 'tls'); } else if ($fs->prefs['email_ssl']) { $swiftconn = Swift_SmtpTransport::newInstance($someTemporaryVariable[0], $someTemporaryVariable[1] || 465, 'ssl'); } else { $swiftconn = Swift_SmtpTransport::newInstance($someTemporaryVariable[0], $someTemporaryVariable[1] || 25); } Did you installed an official release or did you used an inoffical docker?!
Yeah
MySQL 8.0.12, 7.2.9 on debian buster

Steps done to create the problem:
Enter server:port at Mail-Settings

Expected behavior:
smtp.example.com:customport would make use of the custom port

Experienced behavior:
TLS Errors

          if ($fs->prefs['email_tls']) {
              $swiftconn = Swift_SmtpTransport::newInstance($fs->prefs['smtp_server'], 587, 'tls');
          } else if ($fs->prefs['email_ssl']) {
              $swiftconn = Swift_SmtpTransport::newInstance($fs->prefs['smtp_server'], 465, 'ssl');
          } else {
              $swiftconn = Swift_SmtpTransport::newInstance($fs->prefs['smtp_server']);
          }

Should be changed to

          $someTemporaryVariable = explode(':',$fs->prefs['smtp_server']);
          if ($fs->prefs['email_tls']) {
              $swiftconn = Swift_SmtpTransport::newInstance($someTemporaryVariable[0], $someTemporaryVariable[1] || 587, 'tls');
          } else if ($fs->prefs['email_ssl']) {
              $swiftconn = Swift_SmtpTransport::newInstance($someTemporaryVariable[0], $someTemporaryVariable[1] || 465, 'ssl');
          } else {
              $swiftconn = Swift_SmtpTransport::newInstance($someTemporaryVariable[0], $someTemporaryVariable[1] || 25);
          }
]]>