Jump to content


Swarm API isn't accepting login with ticket


  • Please log in to reply
2 replies to this topic

#1 Gurce

Gurce

    Newbie

  • Members
  • Pip
  • 6 posts

Posted 27 November 2017 - 12:49 AM

I've been trying to access our workplace's swarm data via the swarm api, but have run into a problem of request being 'Unauthorized'.


I followed steps here:
- https://www.perforce.../swarm/api.html


When I tried it with the username:password method, I got the 'unauthorized' error:

curl -u "apiuser:password" https://myswarm.url/api/v5/projects
/api/v4/projects/gi-test Unexpected error: 401 : Unauthorized
[{"error":"Unauthorized"}:null]



When I tried it with the apiuser:ticket method (-p), I got the same 'unauthorized' error:

p4 -p myp4host:1666 -u apiuser login -p
curl -u "apiuser:ticket" https://myswarm.url/api/v5/projects
/api/v4/projects/gi-test Unexpected error: 401 : Unauthorized
[{"error":"Unauthorized"}:null]



However, when I tried it via the "host-unlocked ticket" (-ap) method, it worked!

p4 -p myp4host:1666 -u apiuser login -ap
curl -u "apiuser:ticket" https://myswarm.url/api/v5/projects

There was a mention in the docs that:

> For a Helix Versioning Engine that has been configured for security level 3, passwords are not accepted.

This looks like the reason why the "username:password" method failed for me. Our workplace confirmed that we are indeed on security level 3 with ldap logins.

All the same, why was only the host-unlocked ticket accepted and not the standard ticket?

#2 P4Dale

P4Dale

    Member

  • Staff
  • 20 posts

Posted 22 December 2017 - 11:02 AM

Hello Gurce,

The reason an host locked ticket doesn't work is due to the way Swarm uses your ticket to run commands as you on the Swarm machine. The tick are locked to your local machines IP which will be different to the Swarm machines IP address. Below is two reason why Swarm does this:
  • Swarm is running commands as you to ensure you don't see more data than your admins have allowed you.
  • With unlocked tickets means swarm can use your ticket on its own machine and not limited by your IP only.
I hope this helps explain why you Must use "p4 login -ap" when talking to a security level 3 P4D that is connected to Swarm.

Regards,

Dale.

#3 Gurce

Gurce

    Newbie

  • Members
  • Pip
  • 6 posts

Posted 01 February 2018 - 01:09 PM

Thanks Dale, the penny has dropped for me with your explanation.

Just another issue that has stemmed from this -ap ticket, that my boss Pete asked me to chase up with you. Sorry for all the detail, I just think there's no way of avoiding it, to provide some context on what we've encountered.

We are presently trying to automate swarm project creation via our Jenkins server, hence our need for using the Swarm API.

On Jenkins, we are able to store credentials via the "com.cloudbees.plugins.credentials.Credentials" plugin, which saves out the list of our credentials to a "credentials.xml" file.

We decided to add the username:ticket details into this credentials list that we plan to use, it is of the type "Perforce Ticket Credential", as shown:


Posted Image


I then access this username+ticket via Jenkins DSL code and ping the Swarm API to do our bidding.

One concern that Pete and I had was that this "credentials.xml" file then shows this p4 ticket as plain text.

<org.jenkinsci.plugins.p4.credentials.P4TicketImpl plugin="p4@1.8.4">
  <scope>GLOBAL</scope>
  <id>24b19dxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</id>
  <description>Admin-xxxxxxxxx</description>
  <p4port>guxxxx:1666</p4port>
  <username>Admin-xxxxxxx</username>
  <retry>0</retry>
  <timeout>0</timeout>
  <p4host></p4host>
  <ticket>
<value>ticketValueSet</value>
<ticketValue>E0CC5B14xxxxxxxxxxxxxxx</ticketValue>
<ticketPath></ticketPath>
  </ticket>

</org.jenkinsci.plugins.p4.credentials.P4TicketImpl>


We're concerned that an untoward user might go sniffing around in this file, discover this plain-text ticket, and make use of it on another computer (with admin access, as the ticket is not restrained to a fixed pc).

I did a bit of homework to assess which code was responsible for saving out this plain-text ticket.

I noticed that the serialised class of P4TicketImpl is part of the P4 plugin made by perforce, hence the reason for me bringing this up with you.

We notice its behaviour differs when the serialised class of P4PasswordImpl saves its password data into the "credentials.xml" file:

<org.jenkinsci.plugins.p4.credentials.P4PasswordImpl plugin="p4@1.8.4">
  <scope>GLOBAL</scope>
  <id>Admin-xxxxxxxx</id>
  <description>Admin-xxxxxxx</description>
  <p4port>ausxxxx:1668</p4port>
  <username>Admin-xxxxxx</username>
  <retry>0</retry>
  <timeout>0</timeout>
  <p4host></p4host>
  <password>{AQAAABAAAAAQpWQdAzCRep6Su6nVHy0q1b4ebvmAvxLxxxxxx=}</password>
  <allhosts>false</allhosts>
</org.jenkinsci.plugins.p4.credentials.P4PasswordImpl>


So when the P4 plugin stores username:password data into the "credentials.xml" file, it hashes up the password safely. But when it stores a username:ticket there, it doesn't hash up the ticket.

When I looked inside P4PasswordImpl.java, I noticed that password object is of class 'Secret':

import hudson.util.Secret;

public class P4PasswordImpl extends P4BaseCredentials implements P4Password {

/**
* Ensure consistent serialisation.
*/
private static final long serialVersionUID = 1L;

@NonNull
private final Secret password;


Could the ticketValue object that is stored inside "TicketModeImpl.java" also be made of type 'Secret' also?

For now, we'll probably avoid storing our username:ticket credentials inside P4 plugin's P4TicketImpl, and perhaps stick with the P4PasswordImpl type instead (and just put the ticket value in place for the password, just to assure it gets hashed prior to saving it out to "credentials.xml").

Gurce


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users