Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

authinfo incompatibility with saspy module #178

Open
chunky opened this issue Apr 30, 2024 · 0 comments
Open

authinfo incompatibility with saspy module #178

chunky opened this issue Apr 30, 2024 · 0 comments

Comments

@chunky
Copy link

chunky commented Apr 30, 2024

I'm using both saspy [for sas_kernel/jupyter as well as some of our 9.4 systems and SAS Grid], as well as SWAT for working directly with CAS. I spent quite a while trying to debug a connection issue with SWAT that turned out to be due to how my .authinfo was written.

What I had originally looked like this:

IOM_Linux_SASGrid user not_my_real_user password not_my_real_password
default user not_my_real_user password not_my_real_password

SWAT kept having authentication problems, because the syntax with the named config line doesn't work with the parser process in utils/authinfo.py:191 , where it splits on "host|machine|default".

The SASPy documentation is here: https://sassoftware.github.io/saspy/configuration.html#iom , this is the line about "authkey" that's specced thus, that is the line causing the problem:

authkey user omr_user_id password omr_user_password

My workaround was to flip the lines:

default user not_my_real_user password not_my_real_password
IOM_Linux_SASGrid user not_my_real_user password not_my_real_password

And now the "default" one is correctly picked up, [and the rest of the "defs" variable is nonsensical from the perspective of the rest of the parsing code, but it doesn't matter because it doesn't play because default already got returned]

Because the named configs don't make sense with SWAT's configuration, I would suggest the shortest fix that is to split on line breaks first, then split the rest, the way you do now. That way, named configs will be functionally ignored but won't break subsequent records.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant