Open rsenden opened 6 months ago
Hi,
Thanks for reporting this, some initial feedback below.
As for --copy-from not supporting copying access permissions, there's already a PR open for implementing this feature: https://github.com/fortify/fcli/pull/483. As for the 401 response that's silently being ignored, this is a known fcli issue: https://github.com/fortify/fcli/issues/476.
Lately we've been focusing on implementing some major new features (in particular the fcli * action commands) so haven't found time yet to address the PR & issue mentioned above. The 'copy auth permissions' PR author has been busy with other things and I'm waiting for feedback on whether this is fully ready to be merged. Hopefully one or both of these will be included in the near future, but no ETA yet.
As for why you're seeing a 401 error on the auth entities request, we'll need to do some research to see whether we can replicate this issue. As you mentioned that a plain curl command runs successfully, any chance you can try the same with the fcli ssc rest call command and let us know the results?
I did some further research, conclusion is that SSC doesn't allow a CIToken
to update application version auth entities (you can review allowed actions for CIToken
in the SSC WEB-INF/internal/serviceContext.xml
file).
Not sure why the curl
command worked for you, I guess a UnifiedLoginToken
or AutomationToken
was mistakenly used during this test. Even with the SSC API Reference Swagger page, if I explicitly authenticate with a CIToken
, SSC returns an authorization failure when trying to invoke the PUT /api/v1/projectVersions/<id>/authEntities
endpoint. If I use a UnifiedLoginToken
or AutomationToken
, SSC successfully processes the same request.
So, to make this work with fcli, you'll need to pass either username/password, a UnifiedLoginToken
or an AutomationToken
to the fcli ssc session login
command. Given that these tokens allow access to any REST endpoint, you may want to generate these from a user with restricted (non-administrative) role, especially if the token is shared across multiple people/teams. Using custom roles, you can define the exact permissions for that user (which may be a real or technical user), making it a safer approach for sharing a UnifiedLoginToken
or AutomationToken
with other people.
For reference, even when copying an existing application version, fcli won't be able to copy user access settings if the fcli session was created using a CIToken
. Request for updating CIToken
permissions to allow updating user access settings has been shared with SSC product management, for now you'll need to use either an AutomationToken
or UnifiedLoginToken
.
@rsenden Thank you for posting this information, it saved me hours of time trying to figure this out. I recently just switched from a UnifiedLoginToken
to a CIToken
and suddenly the users were not added to the app versions.
It is a bit confusing, I expected the CIToken
to be able to do all automated things.
(copied from other source)
I understand that using
--copy-from
does not copy the auth entities/access permissions from the source. Instead I believe we're directed to use the--add-users
command option. However this option appears to fail to add users, despite the new application version being created successfully. Tracing the logs I see a 401 response that is silently ignored. I have created an fcli ssc session using a ci token, and all other actions appear to succeed.This is from a session in fcli that i ssc session login as a CIToken that was created by an admin user. When I do a REST call directly to the api using the same token it works. For example: