Jump to content

blacs30

Member
  • Posts

    40
  • Joined

  • Last visited

  • Days Won

    3

blacs30 last won the day on March 22 2022

blacs30 had the most liked content!

Profile Information

  • Location
    Germany

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

blacs30's Achievements

Member

Member (4/5)

12

Reputation

  1. So do I understand that you got the workflow partly working now? One thing which doesn't really work yet easily is the usage of the bitwarden-cli in the terminal and in parallel the bitwarden workflow. that is because the session token will change each time an unlock happens and all the secrets are re-encrypted. As a workaround you can use this script to share the same token between the cli and the workflow https://github.com/luckman212/bitwarden-cli-helpers Thanks for mentioning the issue that after logout the wrong item is placed to unlock.. that will require a fix from my side.
  2. Thanks for the logs. 2 more things I haven't asked yet; - Does the bw login work fine in the terminal? Can you try that, and once you are logged in, then the alfred workflow just needs an unlock - run a normal `bw logout` in the terminal and then delete this file: `rm ~/Library/Application\ Support/Bitwarden\ CLI/data.json` (it contains the encrypted secrets, loaded from the bitwarden server); then run bw login again, via terminal and/or via workflow
  3. Oh. I will check the script later once more. Was it ever working for you before?
  4. Mh, difficult to guess what's the problem here. My Alfred has access in the privacy config to Automation, Full Disk access and Accessibility. Not sure if that helps.
  5. Can you try and delete all `com.lisowski-development.alfred.bitwarden` items from keychain and run the login process again? It fails here in the javascript where it would write the received token into keychain.
  6. I just tried it the fuzzy filtering (de-selected Alfreds filter results for the "Search Bitwarden" item). The results were quite good for me. But I had disabled TITLE_WITH_URLS and TITLE_WITH_USER. With those two configs enabled the results are not so good. Maybe it's easier when the text is shorter? I've also set REORDERING_DISABLED to false now to test it little bit more in real live to have my frequently used items on the top.
  7. Have you looked that this page https://github.com/blacs30/bitwarden-alfred-workflow/#search---filtermode Does it change if you try between those 2 modes? In the end I agree with you the search, specially for Bitwarden, is not even close as good as in the Browser plugin (which btw. I haven't used and not even installed for months.)
  8. Mh not sure why. For me it worked fine. Hopefully next time again automatically.
  9. @jpizzle Thanks for pointing this out. The text doesn't match the behavior. Currently it's hard coded to open the url. I can make the action configurable, that makes sense I think. As a workaround you could clone the repo, update this line https://github.com/blacs30/bitwarden-alfred-workflow/blob/master/src/config.go#L400 from "-open" to "output". Then compile the code again with `make build universal-binary` and replace the existing binary with the new compiled one.
  10. Good to hear it's working now. Actually that is an improvement that could be maybe implemented to support both, comma and semicolon separated path. It would avoid problems like this. Regarding the redundant step.. it could be, but I think node also needs to be in the path for the typical bitwarden cli installation.. so I'm not absolutely sure in this case.
  11. @bargepole, that is a strange error, I don't see that it's coming directly from the workflow Golang/js code. Does the bw cli work fine from the terminal? If yes could you try and take the PATH env var content from the terminal and set the Path workflow var to the same value?
  12. Others seem to run the workflow fine on macOS 12. - Please update to the latest workflow if you haven't already (https://github.com/blacs30/bitwarden-alfred-workflow/releases/tag/2.4.1) - remove the one entry in keychain access - use the Bitwarden CLI in the terminal to check that the login works fine (try OTP or email as second factor first) - then try to use the Alfred Bitwarden again
  13. @dhahn Thanks for reporting the issue here (https://github.com/blacs30/bitwarden-alfred-workflow/ would be also a good place alternatively). Could you please do the following 2 things and let me know the result of it: 1. In the keychain access app can you please search for items which have this name "com.lisowski-development.alfred.bitwarden - the result should be 2, one with account name token and the other encryptPassword 2. could you please try to login in the terminal to bitwarden via the bitwarden cli to verify that this works. I haven't tested this workflow with macOS 12 yet. If others have good or bad experience with this workflow on macOS 12 it would be great to know.
  14. You can see the output best in the debug mode of the Alfred workflow. Click on the bug icon at the top right for it. Have you checked these steps https://github.com/deanishe/awgo/wiki/Catalina not sure if they are relevant for this step. Could you please update to the latest version as well. The command changed to .bitauto
  15. @stachmou That issue should be unrelated to the platform (the workflow itself is compiled for both intel and m1). You can check where the Bitwarden cli is located. I assume it's named bw, otherwise it has to be adjusted in the workflow settings (BW_EXEC variable name). Please have a look at the path configuration https://github.com/blacs30/bitwarden-alfred-workflow/#path-configuration, you can get the location of bw with e.g. which bw and then copy the path to the workflow PATH variable. As you might need node and other binaries in the PATH you could try to copy the complete content of the shell PATH variable (in the terminal run echo $PATH) into the workflow PATH variable.
×
×
  • Create New...