How do you set wasabi up to login?

dealtek

https://console.wasabisys.com/#/login?_k=gawhra

It has 3 lines - and 1P skips the 1st line

what it needs to do for some is USERNAME is 1st line
then skip 2nd line
add pass to 3rd line

Q: how do we make that work - cause now 1P - skips 1st line then fills in 2nd = wrong

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

dealtek

littlebobbytables

Hello @dealtek,

So it seems they have added a random number to the ID fields that changes each time. This impedes one of the strategies used by 1Password to fill the correct fields and so 1Password is falling back on more generalised filling attempts, ones that gravitate towards the text "user name".

I believe this alternative approach to creating a Login item should help.

1. Manually create a Login item from within the main 1Password window. Title it accordingly, add your email address and password and set the website field to https://console.wasabisys.com/#/login?_k=gawhra
2. Before you save, click the button titled show web form details.
3. Edit the title of the field from username to AccountName and password to Password.
4. Save.

Do you find this new Login item does better at filling? What we're doing is enabling a different filing strategy to be used, one which seemed to work in my testing just now so hopefully you find as I do that it fills the correct fields.

dealtek

Yes that did the trick - THANKS!

I set the login to submit = Always - however it does not seems to work.... Any Ideas how to get it to auto submit?

littlebobbytables

Hi @dealtek,

That's odd, it submitted after filling for me.

1. What platform are we discussing, is it Mac or Windows?
2. I assume submit after filling is working on other sites?
3. If you edit this Login item to view the submit state is it set to Submit when enabled or Always submit
4. Do you tend to use 1Password's open and fill or do you visit a page and then fill using the likes of the keyboard shortcut ⌘\?

I think that covers all the scenarios I can think of at the moment. I'll see if I can replicate your observations based on your answers and then we can figure out how to get things working :smile:

dealtek

1 - MAC
2 - Yes
3 - Always submit
4 - I always use only keyboard shortcut ⌘\?

• even tried "open and fill" and it does not submit ON FIREFOX or SAFARI but DOES work on CHROME

hope this helps

littlebobbytables

Hi @dealtek,

So I don't know if it's going to be a factor or not but I tested both Safari and Firefox and they both appeared to submit for me. I'm basing this on a little popup at the bottom of the page that tells me they don't know my email address which doesn't pop up if I disable submit after filling. So what's the factor that I alluded to? Most of my testing has been Safari because I have a number of windows and tabs open for my work that has stopped me from quitting Vivaldi. Why would I need/want to? I use a small utility app called Cookie 5 to wipe the various browsers on close. I like to keep very clean browsers and it helps a lot with testing. Even urging various caches with Vivaldi still running this site is determined to remember the contents of fields but as long as I quit a browser and Cookie 5 really wipes everything then I can easily load a clean page.

Why all the explanation? If 1Password doesn't fill a password field it won't submit after filling and if a field already contains the correct value 1Password won't fill the field again. So when I load up the page in a fresh tab in Vivaldi both the username and password fields are already populated and basically ⌘\ doesn't do anything because 1Password sees all the fields already contain the correct values.

Could this explain what you're seeing at all or this doesn't apply here even though it might be a plausible explanation?

dealtek

THANKS SO MUCH for the explanation. Makes sense.

So in my case Safari and Firefox had stored the password in my mac. When I deleted the field data - then used CMD/ it DID submit

YEAH!
THANKS

dealtek

But another issue came up: in firefox I went to prefs and removed the stored login data for wasabi. Then I quit firefox and then went in again to wasabi and it has login filled and ****** showing in the password field (like it's filled in).

BTW: I also deleted the wasabi cookies - but login data remains...

Why is it there after I deleted the pref record and cookies? How do I clear this out?

littlebobbytables

Hi @dealtek,

Well at least we have an answer, even if something can't be resolved I do find that at least understanding can help. Not to say that this is an unresolvable issue mind.

If you purged cookies then I'm thinking local storage. I haven't found anything better yet so it's only if you're feeling somewhat adventurous but this link shows how to identify the presence and delete local storage for a site in Firefox and the link is https://developer.mozilla.org/en-US/docs/Tools/Storage_Inspector

I don't know if it will be of interest to you at all but I am a big fan of Cookie 5. It allows me to set per-browser configurations or default to a global config and I have it set where I whitelist certain sites and for everything else it's all purged when the browser closes. I love it. The various browsers I use for testing are kept clean and tracking cookies get a very finite lifespan on my real browser. It's in the Mac App Store too just in case you're worried about whether it can be trusted or not. It might be overkill but it did mean I could always load a clean version of that page after restarting Safari and Firefox so it was certainly deleting whatever the site was storing.

dealtek

OK - nice idea.

I found some dev tools for firefox - and found the local storage - then saw a var called = ba_state....

lots of data inside - including actual raw text of my username and actual password!!!

SO YOU FOUND IT - NICE WORK !!!!!!

at this point I guess wasabi auto stores this - BUT SEEMS PRETTY INSECURE for the clients - kind of a flaw for a secure storage company - wouldn't you say?

Any way - I was just curious and THANK YOU MUCH for helping with all this!

Dave

littlebobbytables

You're welcome Dave (@dealtek) :smile:

Storing both in such a way doesn't seem like a great idea but I believe for it to be used against you it would require your machine was compromised in some way, either via a backdoor or somebody stole the machine and could access the account. Now my understanding is a bit sketchy so I would need to do some reading up and potentially confer with some colleagues to confirm if that's the case or not. What I can't figure out is what the site feels they gain with this approach. Those that don't care won't think twice and those with sufficient understanding will wipe things like cookies and then wonder what the hell is going on when the field still feels. I certainly understand your point of view. I wonder what their response would be to a query on this?

Anyway, it feels like we've solved the weirdness of this particular site so let us know if you find another and we'll see what we can do :smile:

dealtek

BTW: I just pointed a friend at this page and your solution and it also got things working for him ALSO

for others - remember THIS from above:

Edit the title of the field
from username to AccountName
and password to Password <-- CAP "P"

ALSO TO NOTE: wasabi stores the login user and pass in LOCAL STORAGE even after you quit the browser!

I would think that is a security risk - do you agree?

SOLUTION: if you actually logout of wasabi - THEN IT DOES DELETE THE LOCAL STORAGE USER INFO!!

Thank Again

AGAlumB

ALSO TO NOTE: wasabi stores the login user and pass in LOCAL STORAGE even after you quit the browser! I would think that is a security risk - do you agree?
SOLUTION: if you actually logout of wasabi - THEN IT DOES DELETE THE LOCAL STORAGE USER INFO!!

Wow. I didn't realize that. I agree that I'd prefer to logout and log back in rather than maintaining an active session indefinitely. Than you for sharing!