Jump to content

Recommended Posts

Power Thesaurus Search for Alfred

Search for synonyms and antonyms on Power Thesaurus from Alfred 4.

demo.gif

 

Installation

Get Power Thesaurus for Alfred from GitHub or Packal.

 

Usage

Primary commands:

  • pows <word> — Search Power Thesaurus for synonyms of <word>.
  • powa <word> — Search Power Thesaurus for antonyms of <word>.

For both primary commands:

  •  or ⌘+NUM — Copy highlighted entry to the clipboard
  • ⌘+L — Show full query in Alfred's Large Text window

 

Results

Resulting synonyms or antonyms will be sequentially listed according to user rating.

 

Troubleshooting

SSL Errors

If you're having SSL issues, try temporarily disabling it by setting the workflow environment variable ALFRED_PT_SSL_VERIFICATION to False. This will bypass SSL verification as a workaround while waiting for the SSL certificate to be rectified. You can check Power Thesaurus's SSL certificate status here. Be sure to set it back to True when all's green.

Other Errors

For other errors, please open an issue describing how you got the error and together with the logs from Alfred > Workflows > Debugging Mode if possible. There's no proper error handling in place yet, so we'll have to troubleshoot things this way for now.

 

Licensing and Acknowledgement

This workflow is released under the MIT Licence.

It is heavily based on deanishe's Alfred-Workflow, also MIT-licensed.

By using this workflow, you acknowledge, understand and signify your agreement to Power Thesaurus Website's terms and conditions, and privacy statement.

 

image.png

Edited by clarencecastillo
Add troubleshooting section
Link to comment
  • 2 years later...
  • 1 month later...
1 hour ago, projjol said:

I'm getting a "Max retries exceeded" error. Is this issue local to me or have others faced this as well? Thank you!

 

 

Yep, I'm getting this issue as well. Something to do with verification failure of Power Thesaurus' SSL certificates. Will shortly release a hotfix for this. If this persists, please open an issue here.

 

Edit: I've released the fix for this which can be downloaded from here. Will update the packal page with this update later.

Edited by clarencecastillo
Link to comment
5 hours ago, clarencecastillo said:

Yep, I'm getting this issue as well. Something to do with verification failure of Power Thesaurus' SSL certificates. Will shortly release a hotfix for this. If this persists, please open an issue here.

 

Edit: I've released the fix for this which can be downloaded from here. Will update the packal page with this update later.

You're a star. Really appreciate the prompt fix.

Link to comment
7 hours ago, clarencecastillo said:

I've released the fix

 

Disabling certificate verification is an awfully dubious "fix". Do you know why it's failing? I mean, it's only failing for some users, so the certificate isn't fundamentally invalid.

 

What version of macOS are you (and other users experiencing the problem) using?

Link to comment
22 minutes ago, deanishe said:

 

Disabling certificate verification is an awfully dubious "fix". Do you know why it's failing? I mean, it's only failing for some users, so the certificate isn't fundamentally invalid.

 

What version of macOS are you (and other users experiencing the problem) using?

 

 

According to this, it could be due to one of the "root or intermediate certificates" expiring a few days ago. I'm using Python requests but I'm not quite sure how to bypass this specific cert issue so I just disabled SSL cert verification altogether. Google Chrome is having no problems with it (the official website making similar requests still works) so I thought it would be safe to just ignore.

 

Probably too late to ask this now, but was it working for you (or anyone else) even before the monkey patch? I'm using Catalina 10.15.5.

 

Appreciate it that you're looking into this!

Link to comment
7 hours ago, clarencecastillo said:

but was it working for you (or anyone else) even before the monkey patch?

 

Yes. I downloaded the previous version with verification still turned on. I'm also on Catalina 10.15.5.

 

Can you open Keychain Access, check the "Certificates" category and see if you have this certificate:

usertrust-cert.png.0f8004105b6ca60f52692b0c035de961.png

Not having that would explain why it doesn't work for some users.

 

7 hours ago, clarencecastillo said:

I'm not quite sure how to bypass this specific cert issue

 

The right thing to do is to contact Powerthesaurus and tell them that they're sending an expired certificate. You could also try bundling the above CA cert with requests until Powerthesaurus fix their servers.

 

7 hours ago, clarencecastillo said:

Google Chrome is having no problems with it

 

Chrome is probably using its own bundled copy of the USERTrust CA certificate to verify the certificate chain.

 

7 hours ago, clarencecastillo said:

 so I thought it would be safe to just ignore.

 

It is, but by turning off certificate verification, you aren't only ignoring this error. You've more or less disabled SSL.

 

It's not a big deal with this workflow: there are no sensitive data being passed around. But in general, turning off certificate verification is not something you should do.

 

Seeing as only some users are having the issue, it would be a better idea to make disabling certificate verification a workflow option that users can turn on only if they need it. That way, machines that can connect securely to the API will continue to do so.

 

Link to comment
On 6/2/2020 at 3:06 PM, deanishe said:

Can you open Keychain Access, check the "Certificates" category and see if you have this certificate:

 

Oddly enough, I am seeing this cert in my keychain access but still getting SSL cert verification error.

 

On 6/2/2020 at 3:06 PM, deanishe said:

Seeing as only some users are having the issue, it would be a better idea to make disabling certificate verification a workflow option that users can turn on only if they need it. That way, machines that can connect securely to the API will continue to do so.

 

 

Agreed, will also be easier to maintain it that way once they fix it or in case it happens again in the future. I've opened an issue here to track my progress on implementing this in case anyone else is interested.

 

And thanks for the detailed explanation! Did not expect learning a new thing or two about SSL. Cheers 🍺

Link to comment
12 hours ago, vitor said:

Instead of making it a Workflow Environmental Variable that the user needs to toggle, why not catch the exception (that’s presumably thrown), then disable SSL verification and retry? That way the user doesn’t have to do anything and you’re still getting the best behaviour.

 

3 hours ago, deanishe said:

 

Then you're always making two requests instead of one, which could slow down the workflow considerably, depending on network conditions.

 

Yeah, that would make for a smoother user experience but I don't think this SSL certificate error happens often enough (at most once a year) to make sending two requests per query worth it. Another way could be to programatically set the workflow environment var to False it when it encounters it for the first time, but then there'd be no easy way to check if the SSL certificate has been rectified lest we go back to sending two requests per query or do some other over-engineered way just to do so.

 

Probably more practical to just display a better error message telling the user how to fix it via the Workflow Environment Variable settings.

Link to comment
5 hours ago, deanishe said:

Then you're always making two requests instead of one, which could slow down the workflow considerably, depending on network conditions.

 

Good point, I knew I had to be missing something and that there was a reason that wasn’t your suggestion.


Still, considering how users sometimes ignore or miss even simple Workflow Environment Variables and that SSL errors can be a pain even for developers, I’d consider the automated route anyway:

1. Have a condition that says SSL verification should not happen (e.g., create an empty file in the cache).
2. When making a request, see if the condition is true.
    2.1. If yes, check if it has been set more than X time ago (in the example, check for file modification time).
        2.1.1. If yes, reset / remove the condition.
        2.1.2. If no, do the request without verification.
    2.2. If no (default), try to make the request.
        2.2.1. If it fails, set the condition to true and try again.


That way you’ll only make two requests once (every X time), and it removes from users the responsibility of figuring out if SSL verification should be on or off (which plenty won’t understand anyway). In addition, thanks to 2.1 users also won’t have the responsibility of checking if an SSL connection is possible in the future, because it will be fixed whenever it’s available for them.


It’s more code, yes, but not that much. And being realistic, I don’t believe any (significant amount of) users will ever change the Workflow Environment Variable to true after setting it to false once. They’ll make it whatever it has to be done to have it work and leave it be, negating its purpose (because an automated check that disables it forever would do the same).

Edited by vitor
Link to comment
39 minutes ago, vitor said:

Still, considering how users sometimes ignore or miss even simple Workflow Environment Variables and that SSL errors can be a pain even for developers, I’d consider the automated route anyway

 

Yeah, some SSL-related smarts would be the best way, but it is a fair bit more complicated. I'm not sure I'd bother, tbh. I'd probably just wait until people stopped asking about SSL errors (someone is always too lazy to read the docs), and then push an update removing the ability to disable SSL.

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...