401 unauthorized error... using deleterows query

LabKey Support Forum
401 unauthorized error... using deleterows query WayneH  2018-10-31 09:40
Status: Closed
 

Good morning,

we have been testing a workflow that we have currently running on a project in 16.3 pro+ and tested same on 17.3 community now testing on 18.2 community. The process here includes a perl script that reads existing data in a dataset (specifically the LSID) and is supposed to use that to delete the rows of data in that dataset via deleterows api function and then write new data to that table. We are able to read the data no problem to get the LSID but when we try to delete the rows we get a 401 error. If we delete the data manually we get a 401 error when we try to write the new data to the table... This worked in testing v17.3.. Not sure why we are not getting it to work now.. Is there any change in the api in v 18 that may be causing this? Or are we missing some detail..?

thanks

Wayne H

 
 
Jon (LabKey DevOps) responded:  2018-11-14 14:18
Hi Wayne,

Yes, there have been some changes in how we handle API POSTs, specifically dealing with CSRF.

https://www.labkey.org/Documentation/wiki-page.view?name=csrfProtection

For your API calls to work, you need to pass a CSRF token if your CSRF settings in the Admin Console > Site Settings are set to "ALL POST REQUESTS". You can temporarily set it to "Admin Only" to eliminate the need to do this. However, in LabKey 19.1, this option will no longer be available and all POSTs will require a CSRF token to be passed.

Regards,

Jon
 
Ben Bimber responded:  2018-11-14 14:26
Hi Jon,
 
Does LabKey expect to update any of the client APIs (R, java, perl, python, etc) to automatically handle this, like JS bindings do?
 
jeckels responded:  2018-11-18 16:23
Status: Active
Hi Ben,

The R, Java, and Python client APIs have all been updated such that they should pass the CSRF token seamlessly to the API user. Of course, the code that's using it might need to update the version of the API library to get the new code.

The Perl API doesn't yet handle this. I've logged an issue:

https://www.labkey.org/home/Developer/issues/issues-details.view?issueId=36113

Thanks,
Josh
 
Ben Bimber responded:  2018-11-18 16:28
Status: Closed
Great. We dont actively use perl, but it's good to have them all in parity.

Wayne - glad to see the perl API is still getting some use.
 
WayneH responded:  2018-11-26 12:16
Status: Active
Hi Jon,

thanks for your response.. We made the change to http security.. It was indeed set to 'all process' and not 'admin only' as was the case in our 17.3 test instance.. the one problem that remains is while our data uploads works in our test with all versions attached to postgres db ( tested to 32k records), it does not work with MSSQL server on Labkey. gave a '500 internal error' perhaps related to some constraint in MSSQL as I think we discussed earlier.
 
Jon (LabKey DevOps) responded:  2018-12-10 20:33
Status: Closed
Hi Wayne,

I'm not certain of what 500 Internal Error you're referring to here for MS SQL. But that does sound like a separate issue from the original problem with the CSRF token and using the Perl API.

Regards,

Jon