View Issue Details

IDProjectCategoryView StatusLast Update
0019964mantisbtauthenticationpublic2017-02-01 22:47
Assigned Todregad 
Status assignedResolutionopen 
Product Version 
Target Version1.3.7Fixed in Version 
Summary0019964: Wrong anonymous rights application

Anonymous users have different rights depending on the way they 'login'

Steps To Reproduce

Setup Mantis for anonymous login.
Allow reporting for anonymous user access level.
Delete all cookies.
Login as anonymous with /login_anon.php
You are detected as anonymous.
You can report an issue.
Delete all cookies.
Go to, say, /my_view_page.php
You are detected as anonymous.
You cannot submit an issue.

Additional Information

This also affects on page contents: anonymous that has not truly logged in has no access to the bugs he should not have access to but he sees them in lists.

TagsNo tags attached.





2015-07-23 08:53

developer   ~0051119

Last edited: 2015-07-23 08:56

View 2 revisions

I don't understand the problem at the moment.
Is there a reason (e.g. security) that you set Severity to major?

There is a difference between anonymous visiting the bugtracker (web crawlers, users just viewing, ...) and beeing logged in as anonymous user.
e.g. you will also notice that the current selected project is stored if you are logged in.

We would not need the "Login Anonymously" link if there is no difference.

As a side note: We don't recommend to use another access level than VIEWER for the anonymous account.



2015-07-25 05:16

reporter   ~0051134

We would not need the "Login Anonymously" link if there is no difference.

In this case user should not be detected as 'anonymous' if he did not login as 'anonymous'



2015-08-02 17:36

developer   ~0051176

Last edited: 2015-08-03 02:14

View 3 revisions

I believe the root cause for this is that when a page is browsed anonymously without prior login, the anonymous user's cookies are not actually set. This causes MantisBT API functions such as config_get() to return a generic value.

In this case, it returns whatever value is defined for $g_report_bug_threshold in config file instead of what might be defined in the database (global or project-specific).


EDIT: for the record, removed the "git trunk" product version as the issue likely exists since a very long time.



2015-09-01 01:48

manager   ~0051337

Reducing severity to minor since this is a corner case and we likely had this bug for a long time.



2015-09-07 18:51

developer   ~0051395

Last edited: 2015-09-08 04:34

View 2 revisions

EDIT: please ignore me - I posted this note in the wrong issue...

Issue History

Date Modified Username Field Change
2015-07-23 07:53 badfiles New Issue
2015-07-23 08:53 atrol Status new => feedback
2015-07-23 08:53 atrol Note Added: 0051119
2015-07-23 08:56 atrol Note Edited: 0051119 View Revisions
2015-07-25 05:16 badfiles Note Added: 0051134
2015-07-25 05:16 badfiles Status feedback => new
2015-08-02 17:36 dregad Note Added: 0051176
2015-08-02 17:36 dregad Assigned To => dregad
2015-08-02 17:36 dregad Status new => assigned
2015-08-02 17:36 dregad Product Version git trunk =>
2015-08-02 17:36 dregad Target Version => 1.3.0-beta.3
2015-08-02 17:37 dregad Note Edited: 0051176 View Revisions
2015-08-03 02:14 atrol Note Edited: 0051176 View Revisions
2015-09-01 01:48 vboctor Severity major => minor
2015-09-01 01:48 vboctor Note Added: 0051337
2015-09-06 17:46 vboctoradmin Target Version 1.3.0-beta.3 => 1.3.0-rc.1
2015-09-07 18:51 dregad Note Added: 0051395
2015-09-08 04:34 dregad Note Edited: 0051395 View Revisions
2015-12-06 02:55 vboctor Target Version 1.3.0-rc.1 => 1.3.0-rc.2
2016-06-12 02:37 atrol Target Version 1.3.0-rc.2 => 1.3.0
2016-07-10 07:57 atroladmin Target Version 1.3.0 => 1.3.1
2016-08-28 10:37 atrol Target Version 1.3.1 => 1.3.2
2016-10-02 19:36 atrol Target Version 1.3.2 => 1.3.3
2016-10-30 23:23 vboctor Target Version 1.3.3 => 1.3.4
2016-11-27 08:22 dregad Target Version 1.3.4 => 1.3.5
2016-12-30 16:24 atrol Target Version 1.3.5 => 1.3.6
2017-02-01 22:47 vboctor Target Version 1.3.6 => 1.3.7