origin,在弹窗中打开返回的 url,
然后监听即可。此外别无所需,而未带 origin 创建的链接没有任何变化——行为与以往完全一致。
在使用嵌入式小组件?这些已经为你接好了。 脚本会接收这些
事件,去掉
connect: 前缀后交给 connect.on("success", …)——无需编写 message 监听器、
origin 检查或 popup.closed 轮询。本页是底层的线协议(wire protocol),当你拥有窗口时
——直连模式,或你自己打开的弹窗——就以本页为准来构建。事件只发送到你在链接上设置的确切
origin,且只发送给打开弹窗的窗口。尽管如此,请始终在
监听器中检查 event.origin:任何页面都可以向你的窗口发送消息,而 origin 是消息中唯一无法
伪造的部分。事件列表
发送到你页面的每条消息都是形如{ source: "ayrshare", version: 1, event, ... } 的对象,并且
只要事件与某个网络相关就会携带 network。有两个事件不携带:来自托管关联页面的
connect:closed——在那里它表示你的用户按下了 Done,而不是某次连接结束——以及小组件的
connect:ready(见下文)。由你自己代码合成的结果——被拦截的弹窗,或你的用户关闭的窗口——不是
来自我们,只携带你赋予它们的内容。
嵌入式小组件在一个事件上有所不同。它的
ready 宣告某个插槽
已就绪,而与网络无关,因此不携带 network——而弹窗的 ready 会标明它为哪个网络打开。如果你
用一个监听器同时处理两种界面,请在 ready 上防御性地读取 network。小组件还会新增一个此界面永不发送的 cancelled reason:superseded,即第二次 popup() 调用
替换了仍在进行中的尝试。这里只有一个窗口、一个结果,没有可被替换的东西。
每次连接恰好到达
connect:success、connect:error 或 connect:cancelled 之一。
connect:closed 不在其中——它随后到达,告诉你弹窗是有意关闭的。
connect:success 只在账号保存之后发送,因此紧随其后的
GET /user 已能显示已连接的账号。
connect:error 之后弹窗保持打开,让你的用户能读到出了什么问题。connect:success 和
connect:cancelled 之后它会自行关闭。调试期间可在 URL 后加 &autoClose=false,让它在任何
情况下都保持打开。监听
这段代码做了两件容易被漏掉的事。它检查event.origin,并留意用户手动关闭的弹窗——已关闭的
窗口什么也发不出来,轮询是唯一的察觉方式。
错误
connect:error 携带与 API 其余部分相同的错误码,因此你在这里看到的错误码含义与其他任何地方
一致。专属于此界面的一个:
其余都是社交网络自身的失败,以该失败已有的错误码报告——例如
322 表示 Instagram 授权问题,
其中包括账号仍是 Personal 而非 Professional 的情况。
失效链接以不同方式到达
已过期、已吊销或不存在的链接会在页面得知向哪里发送事件之前就被拒绝,因此它无法发送 事件。你的用户会在屏幕上看到原因及其错误码,而你的页面会在他们关闭窗口时听到connect:cancelled。
要区分这几种情况,请轮询获取 Link Session:它权威地报告
expired 和 revoked,对不存在的链接返回 502。
如果你不想管理弹窗
两个选项,只有第二个会失去事件。 让小组件拥有窗口。 嵌入式小组件会替你打开并监视它,并把 上面的每个事件交付给你的处理器。你仍会在账号保存的那一刻收到success;只是不用编写那些管道
代码。它的框架还意味着大多数网络在到达网络自身登录之前根本不会打开弹窗。
改为轮询。 如果确实无法使用弹窗——服务器端渲染的应用,或在系统浏览器中打开链接的移动应用
——请轮询获取 Link Session。它会在账号保存后立即报告
completedAt 和 completedNetworks,这与 connect:success 本应发送的时刻相同。Telegram 总是
以这种方式完成,因为它在带外完成,没有任何浏览器回调。