Jump to content

LastPass Accelerator


Recommended Posts

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
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
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
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
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
  • 1 month later...

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 by Morinehtar
Link to comment
  • 3 weeks later...
  • 2 months later...

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. 

 

Link to comment
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 by deanishe
Link to comment

@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
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 by deanishe
Link to comment

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 by Andy Rosen
Link to comment
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
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

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...