Skip to content
Notifications
Clear all

Troubleshooting: Users can't save new logins on certain websites

3 Posts
3 Users
0 Reactions
0 Views
(@elliotn)
Estimable Member
Joined: 1 week ago
Posts: 106
Topic starter   [#10800]

We've been evaluating 1Password Business for our data platform team (approx. 45 engineers) for the last three months. Overall, the vault sharing and secret management for service accounts has been excellent. However, we're encountering a persistent, low-frequency issue that's impacting user adoption: certain users report an inability to save new credentials on specific websites. The "Save New Login" dialog simply fails to appear after a successful login. This is not universal; it appears to be tied to specific site architectures.

From our internal tracking, the issue is not browser-specific (observed in Chrome, Firefox, and Safari on managed devices) and occurs despite the 1Password browser extension being reported as "active and working." We've ruled out basic troubleshooting steps like re-installing the extension and restarting the browser. The problem is intermittent but reproducible for specific users on specific sites, suggesting a state or permission issue.

Our current hypothesis centers on two potential vectors within the 1Password Business configuration:

1. **Policy Conflicts:** Our Business account has several security policies applied (e.g., requiring master password re-prompt after 14 days, restricting certain countries). We suspect a race condition where a policy re-evaluation during the login capture event might silently block the save prompt.
2. **Domain Matching Rules:** Complex modern login flows (e.g., OAuth handshakes, login portals that redirect across multiple subdomains) might confuse the extension's heuristic for when to offer the save dialog.

Has anyone else performed structured testing on this? I'm looking for concrete, reproducible patterns. Our internal log capture (with user consent) from the extension's debugging console shows the following when the failure occurs:

```
[info] Popup closed without saving.
[debug] Form detection algorithm: `autofill.js` processed 3 potential forms.
[debug] No form with password field and submit event detected for saving.
```

This suggests the extension is seeing the page but not identifying a savable login event. We are testing a workaround involving custom JavaScript inlets for these problematic sites, but this isn't scalable for a business-wide deployment.

**Key Questions for the Community:**

* Are there known conflicts with specific Content Security Policy (CSP) headers set by modern web applications that can block the extension's injection mechanism?
* Has anyone traced this to a particular 1Password Business policy setting? We've begun a controlled A/B test with a policy-off user group to gather data.
* What is the recommended diagnostic path? Should we be looking at browser `performance.timeline` data to detect blocking scripts, or is the issue entirely within the extension's domain detection logic?

I will compile any shared experiences into a benchmark matrix to identify common denominators. Our goal is to produce a reliable mitigation or monitoring rule to alert when this condition is likely to occur.

-- elliot


Data first, decisions later.


   
Quote
(@james_k_revops_v2)
Estimable Member
Joined: 1 month ago
Posts: 98
 

You mentioned policy conflicts. Have you checked if the specific sites triggering this use non-standard login flows, like a second "security verification" step before the main dashboard loads?

I've seen similar issues where the extension's detection logic times out if a page redirect happens too slowly. Could be a conflict between your corporate "require master password" policy and how those sites handle session creation.


null


   
ReplyQuote
(@cloud_migrate_tom)
Estimable Member
Joined: 4 months ago
Posts: 87
 

Yeah, the policy conflict angle seems plausible. I've seen something similar where a policy enforcing two-factor for vault access caused a silent timeout on sites that used a lot of client-side redirects. The extension seemed "active" but was stuck waiting for a policy check that never completed cleanly.

Have you tried checking the extension's debug logs for those specific users when they hit the problematic sites? It might show a permission denial that isn't surfaced in the UI.

What's your timeline for getting this resolved before full rollout? I'm in a similar evaluation phase and this kind of intermittent issue is exactly what makes my team nervous.


One step at a time


   
ReplyQuote