用 Marionette 接管已登录的 Firefox:把站点自动化跑在真实会话里用 Marionette 接管已登录的 Fir
【摘要】 # 用 Marionette 接管已登录的 Firefox:把站点自动化跑在真实会话里
做站点自动化最烦的一件事不是找选择器,而是登录态。我用踩坑记录换来的结论是:**对于靠会话 Cookie 的站点,别想着复制 Cookie 重放,直接把自动化挂到那个已经登录的浏览器进程上。**
## 一、Cookie 复制为什么必然失败
第一反应通常是把 `cookies.sqlite` 拷出来,再用
用 Marionette 接管已登录的 Firefox:把站点自动化跑在真实会话里
做站点自动化最烦的一件事不是找选择器,而是登录态。我用踩坑记录换来的结论是:**对于靠会话 Cookie 的站点,别想着复制 Cookie 重放,直接把自动化挂到那个已经登录的浏览器进程上。**
## 一、Cookie 复制为什么必然失败
第一反应通常是把 `cookies.sqlite` 拷出来,再用 requests 带上重放。实测在华为云 SSO 上,重放的结果永远是:
```
HTTP 200 redirects=0 final=https://auth.huaweicloud.com/authui/login?service=...
```
状态码是 200,但仍然停在登录页。原因有两个:
1. 关键 Cookie(`cbc-sid`、`HW_id_*`、`J_SESSION_ID` 等)的 `expiry` 是 0,属于**会话级 Cookie**,服务端与浏览器进程生命周期绑定;
2. 部分字段还带设备指纹与 IP 维度校验,离线请求的上下文和浏览器里的上下文对不上。
所以「Cookie 导入」这条路在强 SSO 站点上基本可以直接放弃。
## 二、为什么不是 CDP
Chromium 系可以用 CDP 附着到已开端口,但 Firefox 默认没有等价物。BiDi 在新版本里可用,不过要重启浏览器并带 `--remote-debugging-port`,对我们「不能打扰正在用的窗口」这个约束来说同样不可接受。
## 三、可行路径:profile 副本 + Marionette
核心思路是**不去碰用户的日常 profile**,而是复制一份,让它带着登录态独立运行:
```bash
rsync -a --exclude cache2 --exclude startupCache \
--exclude '*.sqlite-wal' --exclude '*.sqlite-shm' \
~/.mozilla/firefox/<日常profile>/ /path/to/ffuser/
```
然后在副本的 `prefs.js` 里固定两件事,避免端口漂移和代理干扰:
```js
user_pref("marionette.port", 2829);
user_pref("network.proxy.type", 0);
```
启动:
```bash
firefox --marionette -profile /path/to/ffuser --new-window https://example.com
```
之后用 Selenium 附着,关键是 `--connect-existing`:
```python
from selenium.webdriver.firefox.service import Service
svc = Service("/usr/sbin/geckodriver",
service_args=["--connect-existing", "--marionette-port", "2829"])
driver = webdriver.Firefox(service=svc)
```
## 四、三个必须记住的细节
**1. 附着模式不要调 `quit()`。**
`--connect-existing` 下 `driver.quit()` 会把常驻的浏览器一起关掉,登录态跟着没了。收尾用 `driver.service.stop()`。
**2. 会话 Cookie 让浏览器别重启。**
只要进程活着,会话就活着。所以脚本要设计成「先探测端口,不通才拉起」,而不是每次跑都重启一遍。
**3. 原生协议不如 Selenium 稳。**
直接用 socket 走 Marionette 协议,握手能过:
```json
{"applicationType": "gecko", "marionetteProtocol": 3}
```
但 `WebDriver:GetWindowHandles` 会超时。加一层 geckodriver 反而稳定,没必要自己实现协议。
## 五、什么场景值得这么做
- 登录依赖短信/扫码/SSO,无法程序化获取;
- 操作频率低(签到、发布、日报),不值得做长期 token 方案;
- 目标是「人已经登录的会话」,而不是要拿到账号密码。
代价也很明确:**它绑定一台机器、一个用户、一个活着的浏览器进程**。要做服务化,还是老老实实申请 OAuth 或开放平台 token;Marionette 是「够用的临时方案」,不是架构。
一旦接受这个前提,很多原本卡在登录墙上的自动化就能直接跑起来了。
【声明】本内容来自华为云开发者社区博主,不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱:
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论(0)