Jump to content

glawrie

Member
  • Posts

    22
  • Joined

  • Last visited

glawrie's Achievements

Member

Member (4/5)

0

Reputation

  1. I'm sure it is possible, just doesn't appear when I have searched for it here or in help. Thanks in advance for any guidance.
  2. For ages there has been an excellent workflow (Gauth) that provides a simple TFA/OTP generating interface - which is amazingly useful once you get it working. However it is one of the PY2 workflows that is difficult to get working with newer versions of macOS - the latest macOS / XCode updates have broken the hacked py3 version that somene created from the original again ... Given how pervasive TFA/OTP schemes are right now (and increasingly so) it maybe is now time to build this kind of function into the Alfred Core. I can see several benefits that would acrue from so doing: It would be faster - the PY version (particularly on first load after a boot) is quite slow (when it works) It would continue to work when macOS updates - difficult to over state how useful this is ... It could possibly store its secrets in the macOS keychain - Gauth saves them into a plain-text file which is possibly not the most secure approach It could be built into other workflows It is really not complicated to do (utility libraries to support generating the requisite codes exist for most languages it seems) Fingers crossed that this idea gains some support - I think implementing this would be a big step up.
  3. Looks like Alfred 5 breaks this add-on After updating to Alfred 5 (and while using the Python 3 version of Gauth Workflow) the workflow fails. Turned on the debug and the error relates to something called `readPlist` (I'm not a python speaker)... here's the error log: [16:47:54.532] Logging Started... [16:48:04.291] Google Authenticator[Script Filter] Queuing argument '' [16:48:04.400] Google Authenticator[Script Filter] Script with argv '(null)' finished [16:48:04.403] ERROR: Google Authenticator[Script Filter] Code 1: Traceback (most recent call last): File "/Users/glawrie/Sync/AppSync/Alfred.alfredpreferences/workflows/user.workflow.1D847186-5E7D-4AC8-B2A3-B6032E5FD5A7/workflow.py", line 7, in <module> import alfred File "/Users/glawrie/Sync/AppSync/Alfred.alfredpreferences/workflows/user.workflow.1D847186-5E7D-4AC8-B2A3-B6032E5FD5A7/alfred.py", line 22, in <module> preferences = plistlib.readPlist('info.plist') AttributeError: module 'plistlib' has no attribute 'readPlist' Does anyone know what needs to be done to fix?
  4. Hi @vitor - thanks for the heads up on this: will provide a good short-term fix. Is there a wider reason why the effort is on maintaining Python2 rather than migrating the workflows to use Python3? From what little I have read it seems that moving to Python3 would be a better long term solution... but maybe I missed something.
  5. So one step forward, one back... Getting Alfred to find python is relatively painless, open the workflow in alfred workflow panel and click on the gauth Script Filter tile and change 'python' to 'python3', and then repeat this with the fourth of the 'run script' tiles in the second column. On my system at least doing that gets Alfred actually running the python. Fixing the python scripts to run under python 3... haven't got that going yet. Running 2to3 and fixing the file open lines simply push the fail to a later error. Where I am currently is trying to work out what is causing this problem which appears to be not passing meaningful information (so there is something wrong with the alfred.args values... )
  6. I did a bit of digging and turned on Alfred debugger: couple of issues Some modifications are needed to the python scripts to work with Python 3 Alfred is reporting that it is not able to find python even though it is installed I am not so good with Python and I have not tracked down all the issues between Python 2 and 3, but seems they are more complex than just runing 2to3 on the files. For example line 20 of the file alfred.py preferences = plistlib.readPlist('info.plist') Needs to become with open('info.plist','rb') as fp: preferences = plistlib.load(fp) But to get beyond this requires getting Alfred to recognise that python is installed... not sure what modification is needed - on my system python is installed and typing `python gauth.py` into zsh triggers processing of the file via python - but the same from within Alfred fails. If anyone has guidance on how to get Alfred to recognise that python is installed... that would be a helpful addition...
  7. Gauth workflow has stopped working on my system following update to macOS (12.3). Have tried reinstalling the workflow but without success. Gauth add sort-of works - in that you are prompted for a new secret - but nothing happens if you then enter any data. Normal use of guath simply doesn't happen - the option appears in Alfred as you type Gauth... but when you hit space after the keyword you get bounced to entering text for search-engine search. Using Alfred 4.6.4 [1293] - Gauth was working fine with this version before macOS update, so currently suspicion is that it is the macOS version that is behind issue. Anyone got any insights? Anyone see the same issues?
  8. Thank you! I'll see if I can patch it into a workflow 😬
  9. I use a keyboard that for reasons unknown is unable to send the media key codes successfully to macOS - hitting play/pause works to play/pause the currently selected media app, but hitting "next" or "prev" media keys does nothing. If I simulate these keypresses using the macos "keyboard viewer" app then the media apps all respond correctly - but opening the keyboard viewer simply to skip a track is tedious, and I don't have the screen space free to leave the viewer visible all the time. My keyboard provider (logitech) is not so far able to rectify the issue - so while I wait I thought maybe I could use Alfred to send the appropriate media key presses to the macos system in response to a command. Unfortunately the mini-player in Alfred is tied to the Music app and I'm using something else. Is there a way to get Alfred to do this? Thanks in advance for any help.
  10. Sort of wondering about the line 62 in gauth.py secret = secret.ljust(int(math.ceil(len(secret) / 16.0) * 16), '=') The secret I'm getting from Amazon (that works in other authenticators) is 52 chars long - which means that secret after this step has 12 `=` symbols at the end - maybe this not playing nicely with your staged processing of the key (as the final step in the revised approach receives '========' as the input in the amazon case). Or maybe it is OK... but regardless, if anyone has thoughts on how this might be fixed I'd value the input.
  11. Thanks for posting. Have tried to get this to work, but even after pasting in the alternative code I still cannot get Amazon OTP secret to be recognised. If I add the amazon code that works in other OTP solutions direct ~/.gauth the amazon entry does not show up, if I try to add via Alfred (the Gauth Add thing) the workflow reports an error in the format of the submission. Any ideas?
  12. Hi - Yes I got that from reading the other posting (not sure I spotted where the messaging was clearer between 4.0.8 and 4.0.9 beta - too subtle for me). Thanks for your help - have triggered the rebuild now and hopefully that will do the trick.
  13. Thanks - I did search for spotlight in forum prior to posting but it turned up nothing. Will download the beta and see what happens :)
×
×
  • Create New...