[Kea-users] Stork API Key

Eric Graham eric.graham at vantagepnt.com
Thu Dec 15 15:44:43 UTC 2022


Thanks, Rick, for the clarification. I dug into the code to double check that HTTP basic auth is not used.

The API spec is here: https://gitlab.isc.org/isc-projects/stork/-/blob/aa1036c20dd32eaeaa9675b329d8b704dbeeb718/api/users-paths.yaml#L1-L33

If basic auth were in use, there would be a security section as described here: https://swagger.io/docs/specification/authentication/basic-authentication/

Here is the code that authenticates the user for the /session endpoint: https://gitlab.isc.org/isc-projects/stork/-/blob/aa1036c20dd32eaeaa9675b329d8b704dbeeb718/backend/server/restservice/users.go#L54-L68

A use of the middleware to ensure the user is logged in before continuing the request: https://gitlab.isc.org/isc-projects/stork/-/blob/aa1036c20dd32eaeaa9675b329d8b704dbeeb718/backend/server/restservice/middleware.go#L269-L281


In summary, the user provides a username (treated as an email if it contains '@' or a username otherwise) and a password, which maps to their identity. The password is hashed with PostgreSQL's crypt​ function and stored. That identity is tied to the session token, which are passed to the server in the session cookie upon any (authenticated) request and checked for equality and validity (+ expiration) in the database. Basic auth is not checked.



Eric Graham

DevOps Specialist

Main: 605.995.1777

Eric.Graham at Vantagepnt.com<mailto:Eric.Graham at Vantagepnt.com>


[cid:1bf5a212-703c-4706-9ce6-12d3f154e5c9]


Mitchell | Portland | Colorado Springs | San Antonio | Sioux Falls | Springfield | Charlotte

________________________________
From: Frey, Rick E <Rick.Frey at windstream.com>
Sent: Thursday, December 15, 2022 9:22 AM
To: Stefan G. Weichinger <lists at xunil.at>; Eric Graham <eric.graham at vantagepnt.com>; kea-users at lists.isc.org <kea-users at lists.isc.org>
Subject: Re: [Kea-users] Stork API Key

CAUTION: This email originated outside the organization. Do not click any links or attachments unless you have verified the sender.

Questions are venturing out of scope for Kea/Stork and are more with general HTTP but will make a stab at getting you pointed in right direction.



In your second call, you are attempting to use HTTP basic authentication (--user arg to curl) instead of sending the session cookie.  As mentioned earlier in thread, Stork uses sessions for authentication where expiration is currently hard coded to 24 hours.   The session cookie is provided with your successful call to /api/sessions and was stored in your cookie jar file “cookie.txt” with the sample curl command you provided.  In your tests using curl for second call, you just need to omit the username arg and tell curl to use the cookie jar you specified in login post.



Example login (stores session cookie in cookie jar “cookie.txt”):

curl -X 'POST'   'http://10.0.0.230:8080/api/sessions'   -H 'accept: application/json'   -H 'Content-Type: application/json'   -d '{

  "useremail": "sgw",

  "userpassword": "yourpassword"

}'  -c cookie.txt



Example API call using previous acquired session cookie stored in cookie jar:



curl -X 'GET'   'http://10.0.0.230:8080/api/subnets'   -H 'accept: application/json'   -b cookie.txt





From: Kea-users <kea-users-bounces at lists.isc.org> on behalf of Stefan G. Weichinger <lists at xunil.at>
Date: Thursday, December 15, 2022 at 7:46 AM
To: Eric Graham <eric.graham at vantagepnt.com>, kea-users at lists.isc.org <kea-users at lists.isc.org>
Subject: Re: [Kea-users] Stork API Key

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


Am 14.12.22 um 17:22 schrieb Eric Graham:
> I haven't used that platform before, so I don't know for sure, but you
> might find it easier to authenticate for each query, depending on how
> frequent they are.

Trying to figure out these calls now.

curl -k -c cookie.txt -X POST -H 'Content-Type: application/json'
https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2F10.0.0.230%3A8080%2Fapi%2Fsessions&data=05%7C01%7Crick.frey%40windstream.com%7Cbbd393496bb846fdd18e08dadea2c5a7%7C2567b4c1b0ed40f5aee358d7c5f3e2b2%7C0%7C0%7C638067087957637806%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=8x8b7ul2tLF5rrRI5ZibhOuCNRJmHjgoCNk%2Bj%2BOaj5k%3D&reserved=0 -d '{"useremail": "sgw",
"userpassword": "nCNKRxxxxxxxx"}'

returns an OK cookie.txt that in turn also can be used for API calls.

-

But I fail with something like:

curl -X GET -H 'Content-Type: application/json' --user
"sgw:nCNKRxxxxxxxx" https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2F10.0.0.230%3A8080%2Fapi%2Fusers&data=05%7C01%7Crick.frey%40windstream.com%7Cbbd393496bb846fdd18e08dadea2c5a7%7C2567b4c1b0ed40f5aee358d7c5f3e2b2%7C0%7C0%7C638067087957637806%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7TzgD5V2k3CR1iNoomF0b4l33dMNllCT3LxG8qInW%2FQ%3D&reserved=0

Shouldn't that work also? Maybe I have a stupid mistake, thanks.

-

I tried with two user/pw-combos to rule out stuff like special chars in
the password.

--
ISC funds the development of this software with paid support subscriptions. Contact us at https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.isc.org%2Fcontact%2F&data=05%7C01%7Crick.frey%40windstream.com%7Cbbd393496bb846fdd18e08dadea2c5a7%7C2567b4c1b0ed40f5aee358d7c5f3e2b2%7C0%7C0%7C638067087957950303%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=BtMFEJS9SUyz6fTC%2FlOEM7KaiPItnWeGHcVXXUk7ua4%3D&reserved=0 for more information.

To unsubscribe visit https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fkea-users&data=05%7C01%7Crick.frey%40windstream.com%7Cbbd393496bb846fdd18e08dadea2c5a7%7C2567b4c1b0ed40f5aee358d7c5f3e2b2%7C0%7C0%7C638067087957950303%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ElhUq7LmCOV9Wva5InpMPjZ5rI64IvpgtWNKtEeFvg0%3D&reserved=0.

Kea-users mailing list
Kea-users at lists.isc.org
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fkea-users&data=05%7C01%7Crick.frey%40windstream.com%7Cbbd393496bb846fdd18e08dadea2c5a7%7C2567b4c1b0ed40f5aee358d7c5f3e2b2%7C0%7C0%7C638067087957950303%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ElhUq7LmCOV9Wva5InpMPjZ5rI64IvpgtWNKtEeFvg0%3D&reserved=0


Sensitivity: Internal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20221215/4bf9f522/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-m5azpz1m.png
Type: image/png
Size: 7597 bytes
Desc: Outlook-m5azpz1m.png
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20221215/4bf9f522/attachment-0001.png>


More information about the Kea-users mailing list