Andy Rosen Posted May 24, 2021 Author Share Posted May 24, 2021 I'll take a closer look. My only concern is that the workflow doesn't break if alfred-firefox is not installed, or not working. Link to comment
deanishe Posted May 24, 2021 Share Posted May 24, 2021 40 minutes ago, Andy Rosen said: if alfred-firefox is not installed You can call the trigger via AppleScript to test if the workflow's installed (you'll get an error if it isn't). Perhaps you could set a flag? So far, the workflow seems to work perfectly or not at all. Link to comment
Andy Rosen Posted May 26, 2021 Author Share Posted May 26, 2021 Version 3.3 What's new? Support for Firefox @deanishe I'm passing a named pipe to your trigger, then parsing the output from that "file". That should prevent any race condition or polling between calling the trigger and getting the result. GitHub: https://github.com/ajrosen/Alfred Packal: http://www.packal.org/workflow/lastpass-accelerator deanishe 1 Link to comment
deanishe Posted May 27, 2021 Share Posted May 27, 2021 11 hours ago, Andy Rosen said: I'm passing a named pipe to your trigger, then parsing the output from that "file". Smart. I should figure out how to do that and add it to the docs. Link to comment
vitor Posted May 27, 2021 Share Posted May 27, 2021 3 hours ago, deanishe said: Smart. I should figure out how to do that and add it to the docs. The Wikipedia page is concise and clear. Link to comment
deanishe Posted May 27, 2021 Share Posted May 27, 2021 (edited) 37 minutes ago, vitor said: The Wikipedia page is concise and clear. I mean how best to implement it in the workflow, not how to make pipes. Edited May 27, 2021 by deanishe vitor 1 Link to comment
Andy Rosen Posted May 27, 2021 Author Share Posted May 27, 2021 51 minutes ago, deanishe said: I mean how best to implement it in the workflow, not how to make pipes. I first tried getting it from /dev/stdout but it didn't work. I was hoping for a one-liner osascript, like tell Alfred to run trigger | grep. I'm pretty pleased with what we've got though And I finally figured out the right way to quote a reply here. It's a good day. Link to comment
deanishe Posted May 27, 2021 Share Posted May 27, 2021 1 hour ago, Andy Rosen said: I was hoping for a one-liner osascript, like tell Alfred to run trigger | grep. Me, too. It’d be awesome if you could directly get results back from another workflow. I thought about writing the workflow and Firefox client as separate programs, so anything could talk to Firefox via /usr/local/bin/ff-client, but that would have made the workflow much more complex to set up. 1 hour ago, Andy Rosen said: I'm pretty pleased with what we've got though Definitely. I've updated the docs & demo to use a named pipe and changed the workflow to write directly to the specified file (instead of a temp file first). Thanks for pointing out the right way to do it. I'd never have thought of that myself. Link to comment
Andy Rosen Posted May 27, 2021 Author Share Posted May 27, 2021 53 minutes ago, deanishe said: [...] I thought about writing the workflow and Firefox client as separate programs, so anything could talk to Firefox via /usr/local/bin/ff-client, but that would have made the workflow much more complex to set up. It appears that the alfred-workflow executable doesn't actually need Alfred to be running. This wrapper works well enough: #!/bin/bash export alfred_workflow_bundleid=net.deanishe.alfred.firefox-assistant export alfred_workflow_cache="${TMPDIR}" export alfred_workflow_data="${TMPDIR}" export alfred_workflow_version=0 ./alfred-firefox $* 2>&- $ ./ff-client tab-info | jq .alfredworkflow.variables { "FF_INDEX": "19", "FF_TAB": "57", "FF_TITLE": "LastPass Accelerator - Page 2 - Share your Workflows - Alfred App Community Forum", "FF_URL": "https://www.alfredforum.com/topic/15646-lastpass-accelerator/page/2/?tab=comments#comment-86972", "FF_WINDOW": "3" } Link to comment
deanishe Posted May 28, 2021 Share Posted May 28, 2021 7 minutes ago, Andy Rosen said: It appears that the alfred-workflow executable doesn't actually need Alfred to be running. Yup. 31 minutes ago, Andy Rosen said: ./ff-client tab-info | jq .alfredworkflow.variables Or: eval $( ./build/alfred-firefox tab-info -shell ) The executable wouldn't need much changing to work as a general Firefox CLI client. It's the distribution that's the pain. The workflow is already complex enough to set up. I don't want to add a Homebrew tap + package to the list. Link to comment
gordonswaby Posted July 26, 2021 Share Posted July 26, 2021 Hey Andy, Having a small issue. Every time I enter my lastpass password I get a "Not logged in" response. I am 100% confident that my password is correct. What could I be doing wrong? Would appreciate some help. Link to comment
manishie Posted July 29, 2021 Share Posted July 29, 2021 Hi I'm having the same issue as gordonswaby. Cannot login, and 100% positive I'm putting in the correct password. I have parentheses and pound signs in my password, maybe that's why? Link to comment
Morinehtar Posted July 29, 2021 Share Posted July 29, 2021 (edited) Hi @manishie@gordonswaby Answer is in a bug in Lastpass CLI Here is basically the Github thread with the fix : https://github.com/lastpass/lastpass-cli/issues/604#issuecomment-844210600 Long story short : A workaround is to: 1. Open `Account Settings` in your browser (`Open My Vault` → `Account Settings`) 2. Press `Show Advanced Settings` 3. Set `General → Security → Password Iterations` to *exactly* `100100` LastPass will ask for your Master password and re-encrypt your vault. After that using `lpass` *should* work again. It helped me, hopefully it will help you (and others) too Edited July 29, 2021 by Morinehtar skynet01 and iTerence 2 Link to comment
iTerence Posted August 19, 2021 Share Posted August 19, 2021 @Morinehtar That worked for me. Thanks for your help :) Link to comment
skynet01 Posted October 28, 2021 Share Posted October 28, 2021 Great plugin! Suggestion: would be awesome to have each sites Fav icon show up instead of last pass icon for results Just an FYI if you are installing it on Mac OS Monterey the path is now different for brew installs. Maybe this can be added to main thread :) run this to get the actual install path brew info lastpass-cli then add /bin/lpass at the end (or navigate tot that folder and look inside until you find lpass), for me it was: /opt/homebrew/Cellar/lastpass-cli/1.3.3_1/bin/lpass So you have to add that path into lpath command (the default preset example incorrectly shows path to a folder not an actual file) Would be nice if there was an error message notification saying path is incorrect as I had to use the debug to figure out all of the above. Andy Rosen 1 Link to comment
deanishe Posted October 29, 2021 Share Posted October 29, 2021 (edited) 11 hours ago, skynet01 said: then add /bin/lpass at the end (or navigate tot that folder and look inside until you find lpass), for me it was: /opt/homebrew/Cellar/lastpass-cli/1.3.3_1/bin/lpass This is not a good solution because it will break with every Lastpass update. There's normally no reason to directly execute a program from the Homebrew Cellar. Executables are symlinked to $HOMEBREW_PREFIX/bin, which is where you’re supposed to run them from. Better to put export PATH=/opt/homebrew/bin:/usr/local/bin:$PATH at the top of the top-level scripts. Then the workflow should be able to find lpass on Intel and Apple machines. Edited October 29, 2021 by deanishe Link to comment
skynet01 Posted October 29, 2021 Share Posted October 29, 2021 @deanishe thank you!! I updated the path to /opt/homebrew/bin/lpass I was dreading the day I had to update the LastPass-cli and it breaking everything. So would adding that export path in the script should remove the need to have that configuration all together? Maybe the author can update the plugin to support universal path in the future Link to comment
deanishe Posted October 29, 2021 Share Posted October 29, 2021 (edited) 2 hours ago, skynet01 said: So would adding that export path in the script should remove the need to have that configuration all together? Yes and no. It makes it so that you can call Homebrew binaries by name instead of their full path, but if the workflow is already using full paths (e.g. calling lpass as /usr/local/bin/lpass), you’ll need to edit it to just use executable names (e.g. lpass) in order for the workflow to run on both M1 and Intel Macs. Edited October 29, 2021 by deanishe Link to comment
Andy Rosen Posted October 29, 2021 Author Share Posted October 29, 2021 (edited) I originally made the path a workflow variable because it's used in (now) 15 separate shell scripts. My "fix" was to symlink everything in /usr/local to /opt/homebrew 😝. So here's my plan. Default ${lppath} to a new script included in the workflow. That script will find the path to the real lpass and change the workflow variable. BTW, I too would love to see favicons. Fetching them dynamically would be far too slow. I'm thinking about a separate script to do it upon request... Edited October 29, 2021 by Andy Rosen Link to comment
Andy Rosen Posted October 29, 2021 Author Share Posted October 29, 2021 In the meantime I pushed a new version. Version 3.4.0 What's new? Added a Universal Action Link to comment
deanishe Posted October 29, 2021 Share Posted October 29, 2021 6 minutes ago, Andy Rosen said: That script will find the path to the real lpass and change the workflow variable. That's not a good general solution because workflow variables are synced between machines. If one machine is Intel and the other Apple silicon, only one of them will work. Put export PATH=/opt/homebrew/bin:/usr/local/bin:$PATH at the top of your workflow scripts and then run programs by name (i.e. lpass, not /usr/local/bin/lpass). Link to comment
Andy Rosen Posted November 1, 2021 Author Share Posted November 1, 2021 On 10/29/2021 at 6:50 PM, deanishe said: That's not a good general solution because workflow variables are synced between machines. Good point. I hope you're not sharing $alfred_workflow_cache as well? If not it would be a great place to put a symlink. Link to comment
deanishe Posted November 3, 2021 Share Posted November 3, 2021 On 11/1/2021 at 9:04 PM, Andy Rosen said: I hope you're not sharing $alfred_workflow_cache as well? What do you mean? That variable is set by Alfred. Link to comment
Andy Rosen Posted November 3, 2021 Author Share Posted November 3, 2021 I mean the contents of the cache directory are different. If I create a symlink on an Intel Mac to /usr/local/bin/lpass, it won't conflict with a symlink to /opt/homebrew/bin/lpass on an M1 Mac. Link to comment
deanishe Posted November 3, 2021 Share Posted November 3, 2021 4 hours ago, Andy Rosen said: I mean the contents of the cache directory are different. If I create a symlink on an Intel Mac to /usr/local/bin/lpass, it won't conflict with a symlink to /opt/homebrew/bin/lpass on an M1 Mac. That's correct. The cache and data directories are good places for machine-specific stuff. It's not really a good solution to this particular problem, however. Updating PATH to include both Homebrew bin directories is a lot more straightforward, and is in any case unavoidable if the program you're running wants to run other programs. It also seems likely that Alfred will add the native ability to adjust PATH for Homebrew. Link to comment
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now