【免费下载链接】freehirefreehire — the open-source search engine for job seekers项目地址https://gitcode.com/GitHub_Trending/fr/freehire点击查看免费下载本文围绕 freehire 仓库中的 Firefox 发布流程展开Firefox 构建与 Chrome 构建同源但上架 addons.mozilla.orgAMO有独立的一次性人工步骤、源代码包要求、固定的 gecko id 以及基于 JWT 的自动签名链路。读完后你将掌握如何手工完成首次上架、如何准备 reviewer 可复现的 sources ZIP以及如何用两个仓库密钥让后续每个版本自动提交审核。配套阅读Chrome 上架清单 提供完整文案与权限说明扩展开发指南 说明构建命令与 Firefox 差异。Firefox 与 Chrome 构建的关系extension/docs/firefox-addons.md开宗明义Firefox 构建与 Chrome 构建来自同一份源码listing 文案、隐私文本和权限申请理由与 Chrome 版本相同只是减去sidePanel和debugger——Firefox 的 manifest 根本不申请这两个权限。这一点在 extension/wxt.config.ts 中是可以直接印证的事实permissions: [ storage, tabs, scripting, activeTab, identity, downloads, ...(browser firefox ? [] : [sidePanel, debugger]), ], host_permissions: [all_urls],也就是说Firefox 侧保留storage、tabs、scripting、activeTab、identity、downloads与all_urls而sidePanel、debugger仅在非 Firefox 分支注入。二者各自对应一个产品差异没有sidePanel改用侧边栏。WXT 会把同一个sidepanel入口在 Firefox 下产出为sidebar_action。由于 Firefox 的 sidebar 没有“点击图标自动打开”的设置extension/entrypoints/background.ts 在点击事件里显式调用sidebarAction.toggle()这也是 Firefox 要求用户手势才能打开侧栏的原因。没有debugger因此没有“附加定制简历”。chrome.debugger在 Firefox 不存在DOM.setFileInputFiles那条把 PDF 塞进input[typefile]的路径无法实现面板依据import.meta.env.FIREFOX隐藏该按钮。其余差异集中在 manifest 的 Firefox 专属字段后文“gecko id 与登录重定向”一节会详细展开。第一次上架必须在浏览器里手工完成AMO 的发布管道只能给已存在的 add-on 追加版本无法创建第一个 listing。因此首次上架是一次性人工操作拿到两个文件。从buildworkflow 下载extensionartifact或最新的extension-v*GitHub Release也可以本地执行cd extension npm run zip:firefox产物为freehire-extension-version-firefox.zip— 扩展本体freehire-extension-version-sources.zip— 源码包供 AMO 审核使用。进入 Developer Hubaddons.mozilla.org/developers→Submit a New Add-on→On this sitelisted即公开上架→ 上传-firefox.zip。回答“代码是否压缩/打包”时选 yes并上传-sources.zip。给 reviewer 的构建说明原文为Node 24, pnpm and npm. From the archive root:cd design-system pnpm install --frozen-lockfile cd ../extension npm ci npm run build:firefox. The output isextension/.output/firefox-mv2.用 Chrome 上架文档 里的文案填写 listing 并提交AMO 为人工审核。命令与产物在仓库中的对应关系npm run zip:firefox并非 WXT 的默认行为它在 extension/package.json 中被定义为build:firefox: wxt build -b firefox, zip:firefox: WXT_RELEASE1 wxt zip -b firefox,WXT_RELEASE1是关键开关。它让 extension/wxt.config.ts 跳过key字段——发布产物由商店分配 id硬编码的key会与之冲突同时它启用了仅商店产物使用的icon_variantsChrome 侧Firefox 分支则因browser firefox而不注入key因为 Firefox 忽略key改用gecko.id固定身份。sources ZIP 里到底放了什么AMO 会以源码包为准复核打包产物因此 sources ZIP 的构成是硬性要求配置在 extension/wxt.config.tszip: { sourcesRoot: .., includeSources: [ extension/**, extension/.env.production, design-system/**, ], },三个细节值得注意sourcesRoot: ..把压缩包根设为仓库根因为扩展通过file:../design-system依赖设计系统源码包必须同时包含design-system/extension/.env.production被显式列入隐藏文件默认会被跳过而缺少它reviewer 构建出来的扩展会指向 localhost 而不是生产环境审核方构建指令里的npm ci会触发postinstall: wxt prepare生成.wxt/目录这正是cd extension npm ci之后能直接npm run build:firefox的原因。构建前置条件design-system 必须先装依赖仓库在多处强调同一个坑file:/link:链接的包不会被消费方的安装过程带上自己的依赖。因此 reviewer 的指令第一步是cd design-system pnpm install --frozen-lockfile。这一点在 .github/workflows/extension.yml 中有独立步骤与注释CI 也因此单独安装 design-system 依赖否则构建会以MODULE_NOT_FOUND失败。本地验证 Firefox 产物首次上架前建议在本地确认侧栏行为。按 extension/AGENTS.md 的说明执行npm run dev:firefox或npm run build:firefox输出.output/firefox-mv2然后打开about:debugging→ This Firefox →Load Temporary Add-on→ 选择该构建的manifest.json。sidepanel入口在 Firefox 下变成sidebar_action点击工具栏图标即切换显示。gecko id 与登录重定向为什么它必须永远不变extension/docs/firefox-addons.md特别指出add-on id 在wxt.config.ts中固定为extensionfreehire.me所以上架版登录“已经能正常工作”——它的 redirect hash 已在 hire 的允许列表里。这句话的机制在源码中非常具体。登录流程见 extension/lib/auth.tsconst redirectUri browser.identity.getRedirectURL(); const state crypto.randomUUID(); const authUrl ${HIRE_ORIGIN}/api/v1/auth/extension/connect ?redirect_uri${encodeURIComponent(redirectUri)}state${encodeURIComponent(state)}; const responseUrl await browser.identity.launchWebAuthFlow({ url: authUrl, interactive: true });Firefox 的identity.getRedirectURL()形如https://sha1(gecko id).extensions.allizom.org/所以 gecko id 决定了这个 hash。对extensionfreehire.mehash 是13f2644fb08a641dc52d5b7c11faf2fb9775ee26——这个值同时出现在 extension/AGENTS.md 与后端测试 internal/api/handler/extension_connect_test.go 中并被当作“已允许的 Firefox hash”断言通过。服务端校验逻辑位于 internal/api/handler/extension_connect.go要点如下校验项规则scheme必须是https否则报redirect_uri must be httpsport不允许携带端口host 后缀只接受.chromiumapp.org或.extensions.allizom.org标签结构后缀前必须是单个label不能有点号防止a.id.extensions.allizom.org之类绕过允许列表该 label 必须出现在EXTENSION_REDIRECT_ALLOWLIST中空列表直接禁用整个扩展登录流程extension connect is disabledEXTENSION_REDIRECT_ALLOWLIST由 internal/platform/config/config.go 以逗号分隔解析。因此 Firefox 上架的运维动作是明确的把13f2644fb08a641dc52d5b7c11faf2fb9775ee26加进该环境变量与 Chrome 的 id 并列。gecko id 一旦改动hash 随之变化登录会立刻失败——这与 Chrome 侧“key必须固定”是同一个约束。顺带一提minted token 通过 URLfragment回传#token…state…而不是 query避免被日志或Referer带走扩展侧parseAuthRedirect会校验state后才落盘到storage.local。后续每个版本用两个仓库密钥实现自动发布首次上架完成后自动发布只需两件事在 AMO 的 Developer Hub →Manage API Keys生成凭据把它们加为仓库密钥AMO_JWT_ISSUER与AMO_JWT_SECRET。从此任何一次推送到main且提升了extension/package.json的version的提交都会发布一个 GitHub Release并把同一份构建提交到 addons.mozilla.org见 .github/workflows/extension.yml。如果没有配置这两个密钥该步骤会被跳过。CI 的完整链路与门控条件workflow 的触发路径为extension/**、design-system/**与 workflow 文件本身build作业按顺序执行安装 design-system 依赖 →npm ci→ lint → 单测 → 类型检查 →npm run zip→npm run zip:firefox→ 上传extension/.output/*.zip因.output是隐藏目录需要include-hidden-files: true。发布相关步骤有三重门控- name: Publish to addons.mozilla.org if: github.event_name push steps.gh_release.outputs.created true env.AMO_JWT_ISSUER ! 逐条解释github.event_name pushPR 构建只产出 artifact不发布steps.gh_release.outputs.created true只有GitHub Release 是新建的才继续。Release 步骤本身是幂等的——若extension-vversion已存在则输出createdfalse并跳过因此“同一版本重复上传”不会被触发AMO 也会拒绝重复版本号env.AMO_JWT_ISSUER ! 密钥缺失时这一步为 no-op。真正调用签名工具的命令如下sources_path$(find .output -maxdepth 1 -name *-sources.zip) npx --yes web-ext8 sign \ --source-dir .output/firefox-mv2 \ --channel listed \ --upload-source-code $sources_path \ --approval-timeout 0 \ --api-key $AMO_JWT_ISSUER \ --api-secret $AMO_JWT_SECRET几个参数值得记住--channel listed表示提交到公开商店而不是 self-hosted 的未签名版本--upload-source-code把 sources ZIP 一并交给审核方对应首次上架时手工上传的那份包--approval-timeout 0在上传被接受后立即返回不等待人工审核。审核需要数天CI 作业不应阻塞——workflow 注释明确写了这一点。版本号的唯一来源版本号来自extension/package.json的version字段当前为0.1.10workflow 用node -p require(./package.json).version读取并拼成extension-vversion标签。这意味着想让 AMO 收到新版本必须改package.json的version改代码但不改版本Release 与 AMO 提交都会因“已存在”而跳过。上架文案与权限说明的复用边界extension/docs/firefox-addons.md要求直接复用 Chrome 上架文档 的内容但要理解“相同”与“不同”的边界相同的部分名称 freehire、≤132 字符的简短描述、Single purpose“Assist the user with job applications on the page they are currently viewing.”、详细描述、隐私实践收集 PII、认证信息、网站内容、匿名使用行为不收集健康、金融、位置、私人通信、浏览历史、键盘记录以及商店要求的认证勾选项。不同的部分权限理由表要删掉sidePanel与debugger两行因为 Firefox manifest 不申请它们其余storage、tabs、scripting、activeTab、identity、host_permissions: all_urls的理由逐字可用。Firefox 侧还有一项 Chrome 没有的声明data_collection_permissions。它写在 extension/wxt.config.ts 的browser_specific_settings.gecko下browser_specific_settings: { gecko: { id: GECKO_ID, strict_min_version: 140.0, data_collection_permissions: { required: [authenticationInfo, websiteContent], }, }, },注释说明140是第一个读取data_collection_permissions的版本而 AMO 对每个新 listing 都要求该声明。声明的两项正好对应扩展的真实数据面authenticationInfo登录后保存在storage.local的会话 JWT与websiteContent用户提问时读取的页面内容、Autofill 读取的表单字段。这也解释了为什么 Chrome 文档里“收集四类数据”的措辞在 Firefox 侧需要落到这两项必填声明上。上架前后自检清单阶段检查项依据首次上架前extension/package.json的version未被商店占用AMO 拒绝重复版本首次上架前-sources.zip同时包含extension/**、extension/.env.production、design-system/**extension/wxt.config.ts首次上架前本地about:debugging加载.output/firefox-mv2确认侧栏与登录可用extension/AGENTS.md首次上架时gecko id 为extensionfreehire.me未改动extension/wxt.config.ts首次上架后服务端EXTENSION_REDIRECT_ALLOWLIST含13f2644fb08a641dc52d5b7c11faf2fb9775ee26internal/identity/auth/AGENTS.md自动化前仓库已配置AMO_JWT_ISSUER、AMO_JWT_SECRET.github/workflows/extension.yml每次发版version已提升Release 标签为extension-vversionworkflow 版本读取步骤发版失败重试先删除已存在的 Release 与标签再重跑Release 步骤的幂等判断最后一点值得强调Firefox 的自动发布是“只追加版本”不会帮你在 AMO 创建 listing。首次那一步永远留在浏览器里自动化只是把它之后的手工上传动作去掉了审核等待并不会消失——同样的逻辑在 Chrome 侧也成立那里all_urls注定触发人工深度审核。理解这条边界才能正确规划 freehire 扩展在两条商店渠道上的发版节奏。赞分享【免费下载链接】freehirefreehire — the open-source search engine for job seekers项目地址https://gitcode.com/GitHub_Trending/fr/freehire点击查看免费下载相关推荐freehire 浏览器扩展上架 Chrome Web Store 实战清单对齐、权限论证与自动化发布freehire 浏览器扩展上架 Chrome Web Store 实战清单对齐、权限论证与自动化发布 本文以 freehire 仓库中的扩展开源实现为依据AnLinux-App技术原理揭秘Termux与PRoot如何实现免root运行LinuxAnLinux App技术原理揭秘Termux与PRoot如何实现免root运行Linux AnLinux App是一款革命性的开源工具它通过巧妙结合Te工具调用FastAPI性能监控终极指南New Relic与Datadog实战配置FastAPI性能监控终极指南New Relic与Datadog实战配置 在现代Web开发中性能监控是确保应用稳定性和用户体验的关键环节。 FastAPI后端Web框架API设计异步编程上一篇远程工作资源大全awesome-remote-job 精选清单实战指南下一篇dplyr 列重命名完全指南rename() 与 rename_with() 的语法、源码实现与错误校验机制创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考