我在Auth0中尝试了一些新的Hooks功能,特别是注册后挂钩。我希望使用user_id
个人资料字段,即提到的provider|id
here,以便我们可以在应用程序端创建用户记录。我们会将UUID分配给我们的用户,但每个用户都有一个来自Auth0的唯一密钥。
钩子的样本看起来像这样 - 我正在导出可用的整套数据:
module.exports = function (user, context, cb) {
var request = require('request');
request({
method: 'POST',
url: 'https://requestb.in/1ejaxvz1',
body: {
"id": user.id,
"user": user,
"context": context
},
json: true
},
function(error, response, body) {
console.log(user);
console.log(context);
cb(error, response)
});
};
但是,虽然这为我提供了用户的基本ID,但似乎没有关于完整user_id
的信息或关于provider
的任何信息可用于挂钩。换句话说,我只获得provider|12345678
,而不是给我一个看起来像12345678
的完整ID。当我从Auth0获取jwt时,sub
值将返回provider|12345678
。
所以我的问题有两部分: 1)这个完整的用户ID是故意遗漏的原因还是设计疏忽?在撰写本文时,此功能仍处于测试阶段。
2)如果没有完整的用户ID provider|12345678
,我就无法对jwt中的sub
值进行精确匹配。但是,我可以尝试通过删除provider
进行部分匹配。我不清楚这是否是一种有效的做法。我怀疑它不是,但这很难测试。
答案 0 :(得分:1)
Post-registration hook仅在数据库注册上运行,并且user_id
格式在输入数据库时将始终以auth0|
为前缀。但是,这将来可能会改变。
1)是否出于某种原因有意将这个完整的用户ID拒之门外,或者这是设计疏忽?在撰写本文时,此功能仍处于测试阶段。
这是设计使然,但我同意更好的方法是在钩子中同时暴露完整的user_id
,包括提供者。
2)没有完整的用户ID提供者| 12345678,我无法对jwt中的子值进行完全匹配。但是,我可以尝试通过删除提供程序来部分匹配。我尚不清楚这是否是有效的做法。我怀疑不是,但这很难测试。
是的,您必须在user_id
之前加上auth0|
才能获得完全匹配。再次,这不是最佳实践,但是Hooks仍然是beta。