Error 401 ForestAdmin GET route

Hey hope you’re doing great!!!

I created a route GET in one of my collections to get some documents, it was working really well last week and since yesterday I’m getting a 401 for the same request :

without middleware (original version)

router.get('/document/:filename', async (req, res) => {
  const file = await storage.getDocument(process.env.MINIO_BUCKET, `REFUND_REQUESTS_DOCS/${req.params.filename}`);

with a middleware (for test)

router.get('/document/:filename', permissionMiddlewareCreator.details(), async (req, res, next) => {
  const file = await storage.getDocument(process.env.MINIO_BUCKET, `REFUND_REQUESTS_DOCS/${req.params.filename}`);

The error we got :

{"errors":[{"status":401,"detail":"Forest cannot authenticate the user for this request.","name":"Unauthorized"}]}

Thanks a lot!!!

“forest-express-sequelize”: “^7.0.0”

I also removed the calls in this GET route and added a “console.log” in but it’s never printed

Hey @caid :wave:

Not sure I fully got you point here - the 2 code sample throws the mentionned error? or only the second one?
Does this happens on all your environments?
Do you use the role feature and is it configured to allow the details view for the current user you are logged in with?

Thanks in advance :pray:

Hey @jeffladiray

Thanks a lot for your answer!
Both of the samples return the same error :confused: and happened on all my environments (local and remote).
I’m not sure to get what you’re saying about “Do you use the role feature and is it configured to allow the details view for the current user you are logged in with?” I’m logged as a admin and can get the view that is requesting this GET route


Thanks for your answer.

To be sure I fully got your issue:

I also removed the calls in this GET route and added a “console.log” in but it’s never printed

So your /document/:filename route is never call, with or without the permissionMiddlewareCreator.details(), but the call is still triggered when you visit this document collection?

Could you share here a network console screenshot of the request payload that lead to that 401?

I just looked at our recent releases and it does not look like anything was release related to this issue.



I’m sorry for the lack of info, I’m trying to bring some more.
So in my forest I have this view that it get all the documents linked to a refund request :

By clicking on the document name, there is a new tab that appears (the code is in /forest/refund-requests.js) :

      field: 'documents',
      type: 'String',
      get: (record) => {
        if (record.document) {
          // create empty string which will be filled with a div per field listed above - this string will be the value returned
          let documentsList = '';
          // iterate over the list of documents fields
          for (const doc of record.document) {
            const baseURL = `${process.env.APPLICATION_URL}/forest/document/${doc}`;
            // insert the div with the field info to the string that will be returned
            documentsList += `<div style="margin-bottom:5px;">
              <a href="${baseURL}" target="_blank" style="color:#0484fe">${doc}</a>
          return documentsList;

Can you remind me how to get how to get the network console with the inspector please?


Just to be sure, the 401 is triggered when you click on a filename, right?
With the new element you provided, I’m actually not so sure of the issue. It seems like your documents smart fields render only the file URL, am I right? Then, if you click on the link, you get a 401?

If that’s the case, it all depends on where you defined the document/:filename route.
When you click on the link, you’ll be redirected to ${process.env.APPLICATION_URL}/forest/document/${doc} with a GET request (Since the request will be triggered outside our app, directly on your admin backend, this request will then be un-authenticated, and that would explain the 401).

@jeffladiray the route document/:filename is in my /routes/refund-requests.js, it should be a “intern” call, here’s the value of APPLICATION_URL=http://localhost:3310 (it’s the local url of our forest) it should call the document/:filename route then it’s calling the method to get the storage bucket to find the document


Ok, so I did understand your problem correctly.

I guess your route document/:filename is defined with all your other collection routes.
When you click on a document link, you will be redirected to http://localhost:3310/forest/document/xxxx.js, which is not the same domain as http(s)://, thus, will be unauthenticated.

You could see this in action by switching

return ensureAuthenticated(request, response, next);


return ensureAuthenticated(request, response, () => { console.log(request.user); next(); } );

For debug purpose only

In your app.js#~l.53, then and then click on your document link - request.user will be logged before you click the link, and will not be logged when you try to display the document.

I see 2 possible solutions for this issue:

  1. Move the code that display the document (The document/:filename route) before the app.use('/forest', (request, response, next) ... part. That way, the authentication middleware will not be triggered when you click on a document link. Be aware that with this solution, the GET call can be performed without authentication. Even if that’s not an acceptable solution for you, it could worth giving this a shot on your development environment just to make sure your issue is related to this.
  2. If you still want the call to be authenticated, you can also handle the authentication manually doing the same operation as 1., but also add a verification on the token & modifying both documents & document to handle the token retrieval and validation yourself.

Let me know :pray:

Hey @jeffladiray thanks a lot for your reply

Really sorry for my late response, the week was so busy…
It’s woking now, on my local and the remote servers too, I didn’t change anything… so weird
Thanks a lot for your help, I will let you know if it’s coming back one day !

have a good day!