拒絕beforeRemote，我可以使用res.send還是必須使用next（）？

TL; DR 假設客戶端響應以其他方式管理，則不調用beforeRemote中next（）的潛在問題/缺點是什麼拒絕beforeRemote，我可以使用res.send還是必須使用next（）？

嗨。

我有一個模型中的基礎驗證函數beforeRemote鉤子，如果某些條件不符合，需要返回拒絕給客戶端。

我在早期的路由攔截中使用res.send，它完美地工作，並且在beforeRemote中的res.send也似乎工作。但是我很擔心文檔非常清楚地說明必須調用「next」，這意味着我無法手動res.send。

我如何做到這一點在前面的路線

res.statusCode = 401; 
return res.send("Access denied");

如何發揮它的安全

err = new Error("Access Denied"); 
err.status = 401; 
delete err.stack; 
return next(err);

我更喜歡第一種方法，因爲我沒有花「時間」拋出錯誤並在回撥之前刪除堆棧跟蹤（在其他地方需要，因此不能全局刪除）。 res.send對我來說似乎更清潔，但這可能是一種誤解？最後，我不確定是否有任何長期缺陷沒有結束遠程「在環回上下文」（（ctx。）res.send是「只是」表達）。

來源

2016-03-08 Mikael Jensen

第二種方法更靈活。它允許您在發送回覆之前執行一些操作。例如，您可能想要記錄所有被拒絕的請求。或者無論錯誤發生在何處，都可能重定向到家中。

使用next(err)所有你需要做的就是增加一些中間件這樣做，一邊用第一種方法，將最有可能要求在很多地方重複代碼。或者，最終爲了避免這種情況，寫一些能夠做到next能讓你做的事情。

來源

2016-03-08 13:25:09 Overdrivr

是。接下來傳遞「正確」的方式將允許一些額外的處理，res.send將在哪裏結束鏈。但在這種情況下，這正是我想要的，這是一個基本的拒絕/要求，我沒有想到除了拒絕客戶之外，還有什麼需要做任何事情。 –

所以問題的核心仍然是：在beforeRemote –

中調用next（）的潛在問題/缺點是什麼我想說你的情況沒有，你只是結束請求/響應循環早。但是可能有一個缺點。既然你沒有接下來的調用，我很肯定你不能使用[debug strings]正確調試你的服務器（https://docs.strongloop.com/display/public/LB/Setting+debug+strings ）用於強大的遠程處理。 – Overdrivr

拒絕beforeRemote，我可以使用res.send還是必須使用next（）？

回答

相關問題