Python API - Connection with _netrc failing?

LabKey Support Forum
Python API - Connection with _netrc failing? connor henderson  2023-08-22 08:41
Status: Active
 

I'm trying to create a Python script that connects to my LabKey server, however, I'm not getting past authentication when I provide either a username/password or an API key. I've tried moving the _netrc file to the C:/Users/user_account/ path to no avail. I'm not quite sure where I'm going wrong as everything seems to match the documentation.

Python Code

# LabKey Settings
container_path = "Test_Lab"
context_path = "labkey"
labkey_server = "mylabkeyserver.ca"
api_key = 'apikey|8ba5866e0f50c2b9...'

# Debug: print paths and _netrc contents
print(f"{'$HOME path:':20s}", os.environ['HOME'])
print(f"{'$HOME dir:':20s}", os.listdir(os.environ['HOME']))
print(f"{'_netrc contents:':20s}", open(os.environ['HOME'] + "\\_netrc").read())

# Create the connection to the LabKey API
labkey_api = APIWrapper(labkey_server, container_path, context_path, use_ssl = False, api_key = api_key)

# Connect and try to get available roles
print("\nGetting user")
result = labkey_api.security.get_roles()
print(result)

Results

$HOME path:          C:\development\labkey\common
$HOME dir:           ['_netrc']
_netrc contents:     machine	mylabkeyserver.ca	login	apikey	password	apikey|8ba5866e0f50c2b9...

Getting user
---------------------------------------------------------------------------
TimeoutError                              Traceback (most recent call last)
 
 
mohara responded:  2023-08-22 09:29

Hi Connor:

When you're providing the credential in the netrc file, you don't need to also pass the api_key parameter, and in your example it is not set to anything. Try it with the call to APIWrapper reading:

labkey_api = APIWrapper(labkey_server, container_path, context_path, use_ssl = False)

and see if that picks up the credential. In addition, from the response snippet, it looks like your apikey in netrc still includes the "apikey|" prefix, which is [no longer used for newer API keys|(https://www.labkey.org/Documentation/wiki-page.view?name=releasenotes233#dev). Keys generated before this change with the prefix may still work, but it might be worth generating a new one on your server and using that. The key-generation UI will show you an R usage example which will show the key quoted as it should be used. Unless you are on an older version of LabKey Server, it will not include the prefix.

We can also move this topic to your Premium Support Portal if you need more specific assistance with your script and/or placement of the netrc file.

Hope that helps,

--Molly

 
connor henderson responded:  2023-08-22 09:41

We're presently upgrading from 22.7 to 23.7 so our current version uses the prefix. I've tried removing the 'apikey|' prefix and passing it via the _netrc file and by passing as a parameter to the API wrapper to no effect. I can connect to my 23.7 instance that's setup on my local machine; is it perhaps that the API no longer works with 22.7?

 
mohara responded:  2023-08-22 10:09

The API will work with 22.7 of course, but yes, on that older server, the key you generate will have the prefix. Basically, if your netrc has the key as it was generated (and it hasn't expired) it should authenticate. I've also updated the documentation to clarify this and that when you're passing the authentication details in netrc, you should not include the api_key parameter in the API wrapper.

Assuming that's what you're doing, and it's good news that you can successfully connect to your local, another common issue with API wrapper calls is the context_path parameter - does the URL for the 22.7 server and container you want look like this?

http://mylabkeyserver.ca/labkey/Test_Lab

A common configuration for 'non-local/dev' instances is to use a ROOT.xml file instead of a labkey.xml file, meaning that instead the URL would be missing the "labkey/" and you would want to have your script use context_path='' (an empty string).

http://mylabkeyserver.ca/Test_Lab

I think it will work best to move this to your Support Portal, where we can better exchange more specific details of your script and configuration.

Thanks,
--Molly