Mantis Bug Tracker - Forums

paul wrote:Ok, I'm interested, out of interest, whats the requirement/reason for doing this?

Whilst I think I know what you are going to say, and I can see some cases where it might be desirable, i'm just wondering what the rationale you have here is

For instance, anything that refers to a bug by ID - i.e. update/export/etc would need to be changed to display the long ID, otherwise you potentially negate the purpose of hiding it in the first place - or at least, you could give someone a set of userid<>encrypted id's to try to decode. (you mention you are base64_encoding the number - I *assume* you are doing more then that, otherwise it would be fairly easy to reverse)


Paul

paul wrote:hang on - this sounds more like a configuration issue - i.e.

do you actually want to:

a) 'encrypt' the urls

b) ensure that permissions are set up correctly such that users can only see what they should be able to

If B - who are your "users"? - internal / external? etc

paul wrote:Ok - been thinking about this slightly more.

a) Given we have our SOAP API etc, and that you were concerned about guest users - I'm wondering if it would be easier to create a custom 'guest' page that you publish (that removes the 'confidential' information.

b) I think you'll need to show/leave the existing ID same and visible (and somehow add a second verification parameter for what you are doing. - see below for an idea )

P.S. I can't help but think 'encrypting' the url's in this way is the wrong solution to the problem - or at least i'm not understanding the problem correctly (in terms of the code)

---------------

a) We currently utilise the ID's in various places - removing this is going to be problematic.
b) You probably want to check who/what can access the SOAP API in your configuration (as that could be used to bypass what you are trying to do if not configured properly)
c) You will need to be careful about the information that can be disclosed if for example someone uses the 'search'/'filter' issues feature of mantis or the export features of mantis

In terms of 'view.php', quite frankly, i'd leave the id=5 visible (I suspect something will leak it otherwise anyway) but then add a 2nd parameter &verifyid=foo.

Depending on who you are trying to protect (and whether the people are all valid users), i'd then look at:

string_api.php - string_get_bug_view_url and string_get_bugnote_view_url [P.S. search the source for view.php for other places to consider]
view.php - add a check at top of patch to compare id and verifyid values are valid.

So for example, if your concern is that people could copy view.php URL's around, and they were all valid users accessing the system, you could make string_api generate a url that has ?id=5&verifyid=md5( "secret". $id . auth_get_current_user_id() )

Somewhere near the top of view.php it would then be rather trivial to rebuild this with something like:

if( $_get['verifyid'] !== md5( "secret" . $id . auth_get_current_user_id())) {
echo "sorry no pasting links allowed";
}

Of course, this is the wrong solution if you need to be able to copy/paste links to people, but I'm sure you get the idea I'm thinking of. My wider concern is having done this, how many other ways in Mantis there are to bypass this - soap api, filter/search code etc

APPLICATION ERROR #200

A required parameter to this page (id) was not found.

Please use the "Back" button in your web browser to return to the previous page. There you can correct whatever problems were identified in this error or select another action. You can also click an option from the menu bar to go directly to a new section.