Jump to content


Check if current ticket is valid on other hosts?


  • Please log in to reply
10 replies to this topic

#1 dsundara

dsundara

    Newbie

  • Members
  • Pip
  • 4 posts

Posted 16 May 2018 - 07:20 PM

I can use 'p4 login -s' to check if my current ticket (NFS home dir) is valid on the current host, but is there a way to check if my current ticket is valid on another host, without actually trying it on another host? Or another way: How can I tell if my ticket was created with 'p4 login' or 'p4 login -a'? Either command line or API?

#2 Miles O'Neal

Miles O'Neal

    Advanced Member

  • Members
  • PipPipPip
  • 64 posts

Posted 08 June 2018 - 10:59 PM

Why do you not want to just try "p4 -p <other_host:port> login -s"?

#3 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 569 posts

Posted 09 June 2018 - 01:11 AM

The best option I can think of is to use "p4 login -a -p" (which will extend the current ticket and give you a fresh copy of the "hostless" version) and compare what you get to what's in your ticket file.  If they match, your stored ticket is also hostless.

Downside of this is that you need to re-authenticate (at which point maybe you'd rather just "p4 login -a" anyway).

#4 dave.foglesong

dave.foglesong

    Newbie

  • Members
  • Pip
  • 7 posts

Posted 09 June 2018 - 11:23 PM

From a quick test, it looks like if you do "p4 -ztag login -s" the "AuthedBy" field will reflect whether it was created via "p4 login" (where it will report "HostTicket") vs. "p4 login -a" (where it will report "UnlockedTicket").

I did my quick test on a 2017.2 server, it might work differently in other versions.

#5 dsundara

dsundara

    Newbie

  • Members
  • Pip
  • 4 posts

Posted 11 June 2018 - 06:34 PM

View PostMiles O, on 08 June 2018 - 10:59 PM, said:

Why do you not want to just try "p4 -p <other_host:port> login -s"?

I'm talking about client hosts, not server hosts. We have one and only one server. I'm trying to detect if the user ran 'p4 login' or 'p4 login -a' to generate their current ticket.

This is for an automated system, so it has no access to the user's password, only their ticket file. So running 'p4 login -a -p' isn't an option because of the interactive password prompting.

#6 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 569 posts

Posted 11 June 2018 - 07:48 PM

What does your automated system do if the ticket has expired?  Or, assuming it were easy to figure out whether a ticket is going to be portable or not, what would it do if it needed to acquire a new ticket for that reason?

My thinking here is that even if you're trying to avoid having to prompt the user to authenticate, at some point you're going to have to solve that problem no matter what, so I'd focus on being *able* to authenticate first and then figure out from there whether it's worth putting a bunch of time into trying to avoid it.  :)

#7 dsundara

dsundara

    Newbie

  • Members
  • Pip
  • 4 posts

Posted 11 June 2018 - 09:17 PM

If 'p4 login -s' fails we can give the user a clear error message and not launch their jobs onto our internal cloud. However if the user runs 'p4 login' (without the -a), then 'p4 login -s' will pass on the current machine, but that ticket won't be valid for all the other machines in our cloud. That's why I'm trying to find a way to differentiate between a ticket created with 'p4 login' and 'p4 login -a'.

Perhaps there is some clue based on the ticket hex itself?

#8 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 569 posts

Posted 11 June 2018 - 09:47 PM

View Postdsundara, on 11 June 2018 - 09:17 PM, said:

Perhaps there is some clue based on the ticket hex itself?

From what I remember, the ticket is always going to be the same type of hash; the difference is whether the client IP is included in that hash or not.

On the server side there's a sort of global ticket that is unique to that user and shared across all client sessions (until it expires or is otherwise invalidated, e.g. by "logout -a").  When a client runs "p4 login", the global ticket is hashed with the client IP and sent to the client.  If a client runs "p4 login -a", the global ticket is sent without the IP hashing.  When the client tries to authenticate, I believe the server checks whether the client's ticket matches either version (either the raw global ticket that it has stored for that user, or the global ticket hashed with that client's IP to form the IP-bound version).

In either case, what the client has in its tickets file and is using to authenticate is just an md5 hash of "something" and you can't tell simply by looking at it exactly what it's a hash of (well, not without a lot of very time-consuming reverse engineering, or by requesting the global ticket from the server via "p4 login -a" as I suggested earlier).

Given your constraints I think the easiest solution would be to launch a very quick job onto one of your other machines to attempt to authenticate with the ticket, and give the error message if it doesn't work.

#9 dsundara

dsundara

    Newbie

  • Members
  • Pip
  • 4 posts

Posted 12 June 2018 - 06:44 PM

View Postdave.foglesong, on 09 June 2018 - 11:23 PM, said:

From a quick test, it looks like if you do "p4 -ztag login -s" the "AuthedBy" field will reflect whether it was created via "p4 login" (where it will report "HostTicket") vs. "p4 login -a" (where it will report "UnlockedTicket").

I did my quick test on a 2017.2 server, it might work differently in other versions.

That is exactly the feature I was hoping for, thanks!  We're still on 2016.2 so I'll have to wait until we upgrade.

#10 Mailman Sync

Mailman Sync

    Advanced Member

  • Maillist Aggregator
  • 2495 posts

Posted 18 June 2018 - 03:25 PM

Originally posted to the perforce-user mailing list by: Michael Mirman


The hashes are different from login and login -a, but I agree: we can't look at the hash and guess one way or the other.

There is a simple way you can figure out what you need. Look at AuthedBy in the ztag output:



-> p4 -ztag login -s

... User mmirman

... TicketExpiration 259037

... AuthedBy UnlockedTicket



-{503}-> p4 logout

User mmirman logged out.

-{504}-> p4 login

User mmirman logged in.

-{505}-> p4 -ztag login -s

... User mmirman

... TicketExpiration 259198

... AuthedBy HostTicket





--

Michael Mirman

MathWorks, Inc.

508-647-7555



-----Original Message-----

From: perforce-user [mailto:perforce-user-bounces@perforce.com] On Behalf Of Sambwise

Sent: Monday, June 11, 2018 5:50 PM

To: perforce-user@perforce.com

Subject: Re: [p4] Check if current ticket is valid on other hosts?



Posted on behalf of forum user 'Sambwise'.







[https://forums.perfo...post&pid=23563]

dsundara, on 2018/06/11 21:17:10 UTC, said:

Quote

   Perhaps there is some clue based on the ticket hex itself?

Quote



From what I remember, the ticket is always going to be the same type of hash;

the difference is whether the client IP is included in that hash or not.



On the server side there's a sort of global ticket that is unique to that

user and shared across all client sessions (until it expires or is otherwise

invalidated, e.g. by "logout -a").  When a client runs

"p4 login", the global ticket is hashed with the client IP and sent to

the client.  If a client runs "p4 login -a", the global

ticket is sent without the IP hashing.  When the client tries to

authenticate, I believe the server checks whether the client's ticket

matches either version (either the raw global ticket that it has stored for that

user, or the global ticket hashed with that client's IP to form the IP-bound

version).



In either case, what the client has in its tickets file and is using to

authenticate is just an md5 hash of "something" and you can't tell

simply by looking at it exactly what it's a hash of (well, not without a lot

of very time-consuming reverse engineering, or by requesting the global ticket

from the server via "p4 login -a" as I suggested earlier).



Given your constraints I think the easiest solution would be to launch a very

quick job onto one of your other machines to attempt to authenticate with the

ticket, and give the error message if it doesn't work.







--

Please click here to see the post in its original format:

  http://forums.perfor...-on-other-hosts

_______________________________________________

perforce-user mailing list  -  perforce-user@perforce.com

http://maillist.perf...o/perforce-user


_______________________________________________
perforce-user mailing list  -  perforce-user@perforce.com
http://maillist.perf...o/perforce-user



#11 Miles O'Neal

Miles O'Neal

    Advanced Member

  • Members
  • PipPipPip
  • 64 posts

Posted 20 June 2018 - 04:49 PM

For the record, "p4 -ztag login -s" does not show the required information on 2017.1/1534792, either. So 2017.2 or later.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users