Snippets not working with $g_login_method = HTTP_AUTH

[gerald2545]

I succesfully installed Snippets on V2.26.0. I can configure it

but didn't find how to use them in the create or update forms....I don't see any new form field...I don't get errors in the log...
can you post a screenshot of the integration of snippet in the create or update form?

Thank you for your help

Gérald

[dregad]

Bonjour Gérald,

Did you actually define any Global and/or User-specific Snippets ? The selection list will only be shown for the configured fields, when there is at least one Snippet available to the current user.

It could also be a problem with the AJAX not being able to retrieve Snippets from the plugin's REST API back-end, but in this case you should see something in the browser's console log.

[dregad]

I added some explanation and screenshot to the README file.

[gerald2545]

hi
Yes I did create global (and then user) snippets. I Will check the console log.
Thank you

Gerald

[gerald2545]

OK, I get an error in the console : 403 API token not found

I never used webservices in mantis. I did some conf but still have the issue :
create a token in My Account > API Token
be sure $g_webservice_rest_enabled is ON

same 403 error

[dregad]

This is really weird.

It should not be needed to define an API token here at all, because for "internal" REST API calls such as the one used to retrieve the Snippets, users are normally authenticated automatically, using their MantisBT session cookie. This is the code that handles it.

So apparently the request is made with an Authorization: header, which is totally unexpected and I don't know how it could happen.

Can you provide details about the failing XHR request ?

[gerald2545]

Which details do you exactly need?

coul it be related to the auth method I use? : HTTP_AUTH

[dregad]

Which details do you exactly need?

• Request (URL and headers)
• Response (headers, status code)

From browser console, you should be able to export the request as a .HAR file, that would be fine.

coul it be related to the auth method I use? : HTTP_AUTH

Maybe, I don't really know as I never actually used Mantis with that authentication method, and TBH I have little knowledge of it.

Reading https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication, I see that it uses the same Authentication header that the MantisBT REST API expects so it is quite possible that there is some kind of conflict there.

Can you maybe make a test with another authentication method, to see what happens ?

[gerald2545]

hum I prefer not to link a har file with all urls...

My request :

GET /Mantis/api/rest/index.php/plugins/Snippets/data/5770 HTTP/1.1
Host: XXX
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:123.0) Gecko/20100101 Firefox/123.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate, br
X-Requested-With: XMLHttpRequest
DNT: 1
Authorization: Basic XXX==
Connection: keep-alive
Referer: https://XXX/Mantis/view.php?id=5770
Cookie: MANTIS_collapse_settings=|sidebar:0; MANTIS_MANAGE_USERS_COOKIE=0%3Ausername%3AASC%3A0; MANTIS_PROJECT_COOKIE=40; PPA_ID=mleuaohce6if0pfna80ksq6d50; webfx-tree-cookie-persistence=wfxt-4+wfxt-6+wfxt-8+wfxt-22+wfxt-26; PHPSESSID=hsjpcqls0u46qu7l1mo7ssbfe2; MANTIS_secure_session=0; MANTIS_STRING_COOKIE=XXXXXX; MANTIS_BUG_LIST_COOKIE=5770%2C5768%2C5763%2C5705%2C5749%2C5754%2C5760%2C4932%2C5755%2C5688%2C5557%2C5646%2C5693%2C5652%2C5139%2C5520%2C4583%2C5619%2C5535%2C5547%2C5584%2C5544%2C5511%2C5614%2C4595%2C5598%2C5543%2C5597%2C5571%2C5564%2C4746%2C5559%2C5486%2C5468%2C5484%2C5491%2C5487%2C5440%2C5534%2C5554%2C5516%2C5533%2C5433%2C5466%2C3193%2C5147%2C2524%2C4492%2C563%2C5473
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin

The response :

HTTP/1.1 403 API token not found
Date: Thu, 14 Mar 2024 09:01:28 GMT
Server: Apache
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Powered-By: PHP/8.0.30
Cache-Control: no-store, no-cache, must-revalidate, max-age=0
Last-Modified: Tue, 31 Oct 2023 20:46:08 GMT
Set-Cookie: MANTIS_collapse_settings=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; SameSite=Strict
X-Mantis-Version: 2.26.0
Content-Length: 0
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8

I would like to use the default authentication in Mantis (login/password from database) for years, but as it is still using MD5, I can't....so I rely on HTTP_AUTH which is the only method I can implement, but I have to modify source of mantis whenever I install a new version

I added a note in the issu for the use of bcrypt

Thank you for your help

Gérald

[dregad]

but as it is still using MD5, I can't

Yes I know, this is pretty bad and has been a long-standing issue, but it's highly complex to fix it properly and sadly I never find the time to do it... Sorry 😞

Authorization: Basic XXX==

So this is as I suspected, and most likely the root cause, because the REST API just checks for existence of Authorization header to determine if it should process the request as an "internal" API call (authenticated via Mantis cookie), and does not verify the actual contents, so this is interpreted as a regular API token but it's not.

This could be considered a bug in MantisBT core actually. Need to think about it. @vboctor your feedback on this would be appreciated.

I'm afraid there is no immediate and easy solution to this. Some ideas to play with:

• disable HTTP Auth for /api/rest/* path
• modify api/rest/restcore/AuthMiddleware.php to properly detect HTTP Auth vs "normal" REST API auth and ignore it

Not having a working setup to reproduce this locally, it is a bit difficult for me to test this properly, because I can only "fake" things by submitting manually constructed requests.

[dregad]

but as it is still using MD5, I can't

Yes I know, this is pretty bad and has been a long-standing issue for years, but it's highly complex to fix it properly and sadly I never find the time to do it... Sorry 😞

Authorization: Basic XXX==

So this is as I suspected, and most likely the root cause, because the REST API just checks for existence of Authorization header to determine if it should process the request as an "internal" API call (authenticated via Mantis cookie), and does not verify the actual contents, so this is interpreted as a regular API token but it's not.

This could possibly be considered a bug in MantisBT core actually. Need to think about it. @vboctor your feedback on this would be appreciated.

I'm afraid there is no immediate and easy solution to this. Some ideas to play with:

• disable HTTP Auth for /api/rest/* path
• modify api/rest/restcore/AuthMiddleware.php to properly detect HTTP Auth vs "normal" REST API auth and ignore it

Not having a working setup to reproduce this locally, makes it is a bit difficult for me to test this properly, as I can only "fake" things by submitting manually constructed requests.

[dregad]

Similar problem https://mantisbt.org/bugs/view.php?id=25362