xanadublakublaconch / pysdtoken Goto Github PK

When setting dll_name in SDProcess constructor the self.process never gets set to the path passed in.

sd = SDProcess(pin_style='PINPad-style', dll_name='C:\Program Files\RSA SecurID Token Common\stauto32.dll')

Traceback (most recent call last):
  File "c:/CODE/rsa/rsa.py", line 4, in <module>
    sd = SDProcess(pin_style='PINPad-style', dll_name='C:\Program Files\RSA SecurID Token Common\stauto32.dll')
  File "C:\CODE\rsa\rsa\lib\site-packages\pysdtoken\pysdtoken.py", line 258, in __init__
    self._open_service()
  File "C:\CODE\rsa\rsa\lib\site-packages\pysdtoken\pysdtoken.py", line 275, in _open_service
    svc_open: Any = self.process.OpenTokenService
AttributeError: 'SDProcess' object has no attribute 'process

Update pysdtoken to enable the option of passing a dll path to SDProcess.

If not passed, load defaults for platform.

get_tokens() returns the correct count, but any index over 0 returns '' for fields (serialnumber, username, etc)

Hi, my Operating System is 64bits but my soft token is 32bits. I don´t know why but it is the homologated version by the company so I can't change it.

So I changed the "C:/Program) Files\RSA SecurID Token Common\stauto32.dll" to "C:/Program) Files (x86)\RSA SecurID Token Common\stauto32.dll"
I know it is not the best way to solve it but I thought it might work.

here is the error I'm facing after that:

from pysdtoken import SDProcess
sd = SDProcess(log_level='DEBUG')

(output)
DEBUG:pysdtoken.pysdtoken:Pin style set to PINless
DEBUG:pysdtoken.pysdtoken:No dll name passed in during initialization. Determining correct default from platform/arch
DEBUG:pysdtoken.pysdtoken:This is a windows platform.
DEBUG:pysdtoken.pysdtoken:This is a 64-bit platform.
INFO:pysdtoken.pysdtoken:Using path C:\Program Files (x86)\RSA SecurID Token Common\stauto32.dll
DEBUG:pysdtoken.pysdtoken:dll path C:\Program Files (x86)\RSA SecurID Token Common\stauto32.dll exists.
DEBUG:pysdtoken.pysdtoken:Loading C:\Program Files (x86)\RSA SecurID Token Common\stauto32.dll using ctypes windll method
DEBUG:pysdtoken.pysdtoken:[WinError 193] %1 is not a valid Win32 application
ERROR:pysdtoken.pysdtoken:Error finding Soft Token service.
DEBUG:pysdtoken.pysdtoken:Destructor called. Attempting graceful close of SDProcess

Any suggestion?

In order to better serve its function as a library loaded by other scripts I believe it would be best to reduce the verbosity of pysdtoken.

In my opinion, the best way to do this would be to use the logging module and replace the existing error and debug print statements with the equivalent library call.

I'm not sure if you're already doing this, but I would be happy to do so myself as well.

My current thought is to set a global log level at the module level and add a kwarg to SDProcess init to allow overriding it if the caller wants something more verbose.

Nice work on the rewrite, it looks nice!

There are a few issues that are preventing this from working on Mac, unfortunately I'm fairly limited on time currently so I can't submit suggested changes, but I can document what I ran into.

import ctypes.wintypes doesn't work on mac (or at least it's not working for me), I'd suggest making this import platform specific if possible in both _sdauto.py and pysdtoken.py.

The library load on mac isn't working, that is the right path, it just doesn't work for whatever reason. I reverted this back to the find_library approach and it seems to be working fine.

svc_get_code.argtypes on line 526 is causing the call to GetCurrentCode to fail, it doesn't seem to like the type of the serial variable (error is "expected LP_c_char_p instance instead of bytes). Commenting it out bypasses this, trying to convert it to the type it expects is possible, but it doesn't seem to like it. (to convert to c_char_p it wants bytes, but if I make it a bytes before converting to c_char_p I end up not getting a token code)

In my environment it doesn't like the relative import you're doing for _sdauto, may get a different result if installed though pypy though. Removing the . worked for me.

The execution time of close_service() is rather long on Mac, On average I'm seeing around 2 seconds to execute.

I've noticed that if I add a breakpoint right before the call to the C API, then wait a few seconds, when I proceed the function executes and finishes very quickly. I'm not sure why this would be the case.

I'd be curious to see how it performs on other people's systems. To that end, I wrote a quick benchmarking script.

import pysdtoken
import time

count = 0
final_count = 5
avg_tt = 0.0
avg_ct = 0.0

while count < final_count:

    st = time.time()
    sd = pysdtoken.SDProcess()

    cts = time.time()
    sd.close_service()
    cte = time.time()
    et = time.time()

    tct = cte - cts
    tt = et - st

    avg_tt += tt
    avg_ct += tct

    print(f"Test #{count + 1}: Total Time: {tt} | Close Time: {tct}")
    count += 1

print(f"Total Time Avg: {avg_tt / final_count} | Close Time Avg: {avg_ct / final_count}")

Example output:

• Windows (without a token)

Test #1: Total Time: 0.6615047454833984 | Close Time: 0.5024900436401367
Test #2: Total Time: 0.6069846153259277 | Close Time: 0.5006721019744873
Test #3: Total Time: 0.6115283966064453 | Close Time: 0.5024893283843994
Test #4: Total Time: 0.6078929901123047 | Close Time: 0.5015802383422852
Test #5: Total Time: 0.6242508888244629 | Close Time: 0.502490758895874
Total Time Avg: 0.6224323272705078 | Close Time Avg: 0.5019444942474365

• Mac (with a single token)

Test #1: Total Time: 2.953191041946411 | Close Time: 2.512363910675049
Test #2: Total Time: 2.7152068614959717 | Close Time: 2.51251482963562
Test #3: Total Time: 2.693143129348755 | Close Time: 2.5085389614105225
Test #4: Total Time: 2.6996309757232666 | Close Time: 2.5180001258850098
Test #5: Total Time: 2.7025959491729736 | Close Time: 2.5183968544006348
Total Time Avg: 2.7527535915374757 | Close Time Avg: 2.5139629364013674

Edit:

It appears it's a fairly significant portion of the total execution time even on windows, I wonder why that would be.

I'm receiving a TypeError (byref() argument must be a ctypes instance, not '_ctypes.PyCArrayType') when self.process.EnumToken executes.

The exception appears to be triggered by the byref(lpTokens) arg.

Code is current version cloned from repo, execution environment is OSX Mojave. Python version is 3.7.2.

I have 0 experience with C type languages, to this error is throwing me for a loop.

Update:

I tested on Windows 10 as well with the 64bit client v5.0.2 and I'm getting the same result.