Jump to content

blacs30

Member
  • Posts

    40
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by blacs30

  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.
  16. Update: Version 2.3.0 is released. Get it from github https://github.com/blacs30/bitwarden-alfred-workflow/releases/tag/2.3.0 After some months I am releasing this version which adds 2 features which were requested: - The auto lock service locks the Bitwarden workflow after every start and after a configurable time read more here - The auto sync service which syncs Bitwarden in the background multiple times a day with configurable times see more here
  17. @jim465 This issue looks unrelated to the workflow itself but related to either the node or bitwarden-cli installation itself. How did you install bitwarden-cli, via brew or npm? I assume that a simple bw command like `bw -v` will fail as well? Try reinstalling it.
  18. Thanks for this update. That was the reason for me not to update yet. So I'll wait for 11.2 to be released.
  19. Partly I would say it is implemented. Per default it shows "show more" with the modifier keys command + option (or alt). It shows every possible, used field for each item. any of this can be copied. just it's not currently possible to copy only a part of a field, e.g. a part of a note. Secure note content is hidden in the workflow and is treated like a password.
  20. Good that you ask and not just "trust" or "hope". Little snitch is a great firewall which can show up all the hidden traffic going out from applications.
  21. Thank you @deanishe, was only my second golang project but with the Alfred go package provided by you it was fun, and the github interactions since then grew. Currently there is one open improvement on github which makes sense to me: optional time based lock of the Bitwarden workflow. As said already, the encryption key is stored in Keychain and it stays there until manually "lock" or "logout" is called from the workflow (or manually deleted via Keychain) or it get's invalidated by another Bitwarden cli client login in the meantime. The locally cached data also doesn't contain any secrets (unless secrets are put into non secret fields like username or name of the secret).
  22. With version 2.0.0 I have rewritten the complete workflow and added many new features. I've released version 2.0.3 now and updated the first post in this thread You can find the latest version on github https://github.com/blacs30/bitwarden-alfred-workflow/release
  23. If Alfred is allowed to send notifications you should set a confirmation notification like this (screenshot 1) You can also double check the keychain if items have been created there. Open the app "Keychain Access", search for "bitwarden", you should be able to see couple of entries, but at least the one for the email-address. Can you try to search for an item like "bw google", it could be that you also need to run "bwunlock", that is needed in case bitwarden cli unlock is run in the meantime. It is so that bitwarden then invalidates the previous generated session key. Thanks @deanishe taking part here as well, it's an honour I hope to soon fully rewrite this workflow in go with help of your library.
  24. Also sorry to you @thomasSDK for my very very last reply. I will configure my notifications here on the forum. This error you showed looks heavily like this one https://stackoverflow.com/questions/53603246/strange-error-running-osascript-e-command-on-macos-mojave
  25. I'm sorry not to have answered before @Al30 . I think I messed up my notifications here from the forum. Do you still need help? For the logs it looked like that the setting for 2fa mode might have been wrong. I would ask you to try to login via cli in the terminal. If the cli asks you to choose an 2fa auth method (which only happens if multiple 2fa ways are setup) then you need to configure the method otherwise it's 0.
×
×
  • Create New...