解析服務器Node.js SDK：替代Parse.User.become？

我想將我的客戶端應用程序與Parse服務器完全分離，以便將來切換到其他Baas /自定義後端。因此，所有客戶端請求都將指向一個node.js服務器，該服務器將代表用戶向Parse發出請求。解析服務器Node.js SDK：替代Parse.User.become？

Client <--> Node.js Server <--> Parse Server

因此，我需要Node.js的服務器能夠在用戶之間進行切換，所以我可以保持自己的認證的情況下。

我知道如何authentificate，然後保持用戶的sessionToken，我已經我的研究比「接受」解決這個問題的過程中看到的是調用Parse.User.disableUnsafeCurrentUser，然後使用Parse.User.become()當前用戶切換到一個發出請求。

但是，這感覺hackish，我敢肯定，它遲早會導致競爭條件，其中當前用戶被切換，然後請求Parse。

我發現的另一個解決方案是不關心Parse.User，並使用masterKey保存服務器的所有內容，但這會使服務器負責ACL。

有沒有辦法讓除了兩個以外的不同用戶提出請求？

來源

2016-06-22 DrakaSAN

對後端的任何請求（query.find(),object.save()等）都將可選options參數作爲最終參數。這使您可以指定額外的權限級別，例如強制使用主密鑰或使用特定的會話令牌。

如果您有會話令牌，則您的服務器代碼可以代表該用戶發出請求，從而保留ACL權限。

假設您有一張Item對象表，我們依賴ACL來確保用戶只能檢索自己的項目。下面的代碼將使用一個明確的會話令牌，並只返回項目，用戶可以看到：

// fetch items visible to the user associate with `token` 
fetchItems(token) { 
    new Parse.Query('Item') 
    .find({ sessionToken: token }) 
    .then((results) => { 
     // do something with the items 
    }); 
}

become()真的設計的解析雲代碼的環境下，每個請求住在沙箱中，並且你可以依靠每個請求的全球當前用戶。它在Node.js應用程序中沒有意義，我們可能會棄用它。

來源

2016-06-22 19:48:48

我最近寫了一個NodeJS應用程序，並有同樣的問題。我發現Parse.User.disableUnsafeCurrentUser和Parse.User.become()的組合不僅是駭人聽聞的，而且還導致了其他一些我無法預料的問題。這就是我所做的：我使用了 Parse.Cloud.useMasterKey();，然後按照會話ID加載當前用戶，就好像它是普通用戶對象一樣。它看起來像這樣：

module.exports = function(req, res, next) { 
    var Parse = req.app.locals.parse, query; 
    res.locals.parse = Parse; 
    if (req.session.userid === undefined) { 
    res.locals.user = undefined; 
    return next(); 
    } 
    Parse.Cloud.useMasterKey(); 
    query = new Parse.Query(Parse.User); 
    query.equalTo("objectId", req.session.userid); 
    query.first().then(function(result) { 
    res.locals.user = result; 
    return next(); 
    }, function(err) { 
    res.locals.user = undefined; 
    console.error("error recovering user " + req.session.userid); 
    return next(); 
    }); 

};

此代碼顯然可以優化，但你可以看到一般的想法。上行：它的工作！缺點：不再需要使用Parse.User.current()，並且在後端需要特別小心，即在未經許可的情況下某人覆蓋數據的情況不會發生。

來源

2016-06-22 09:12:06

所以你正在使用我找到的第二個解決方案。我明白有人確認它的工作，但如果可能的話，我寧願不必在服務器上進行權限檢查。 – DrakaSAN

哎呀 - 我有點在第二個解決方案的問題上錯過了那一段。抱歉!是的，沒有ACL強制執行是令人討厭的，它實質上意味着您必須明確檢查每個用戶是否允許他讀取或寫入。 –

downvote的解釋會很好... –

解析服務器Node.js SDK：替代Parse.User.become？

回答

相關問題