uselagoon / machinery Goto Github PK

go-bindata has not had any commits recently, and go has the go:embed functionality now which we can leverage in machinery quite easily, almost drop in replacement for how we leverage it

https://pkg.go.dev/embed

The AddNotificationToSlack and others also allow an organization: Int when being created so they are assigned to an organization. Organization owners are allowed to run this with the ID provided and it will create the notification in the organization.

It would be great for machinery to support this in its schema and other functions. If the provided ID to the existing mutation is not provided (1+) then it does not provide the ID to the mutation variables

I was trying to use AddGroupToProject and I think I've found a discrepancy.

type ProjectGroupsInput{} takes a ProjectInput{} which takes a uint Id along with the project name.

It also gets an array of GroupInput. which is an alias for ProjectInput so takes the same Id and Name.

However a group id is not a uint, it's a uuid.Uuid in type Group{}

So, my question is, do we need the Name at all if we have the Id for both ProjectInput and GroupInput? More importantly, should we have a new type:

 type GroupInput struct {
   Id *uuid.Uuid,
   Name string,
 }

Sometimes you may need a query that is a bit more specific than what is offered here

We should provide a way to provide a custom graphql query/mutation and the response being just the raw JSON response from the api

This issue tracks the rollout of application security in CI, including:

• Dependabot
• CodeQL
• secret scanning
• private vulnerability reporting
• dependency review
• OpenSSF scorecard and best practices
• release signing
• release SBOMs
• test coverage
• code linters

As we're seeing more usage of this library amongst our own tooling, and that other people may be using this in their own tools too, we need to be more aware of when a particular function call may require elevated permissions than what general Lagoon RBAC would offer. For example, when a query or mutation requires platform-owner permission or greater, we should make this obvious some how in the query or mutation function name, or namespace them better within the client.

Also, recreating standard queries try to be as RBAC neutral where possible. This would allow for permission errors that would be returned to be genuine based on the requests that the user has performed knowingly. Some of this may not be possible with the current APIs structure, where some fields are retrievable by some roles, but we could still try to be as close to this as possible.

I was looking to get a project ID, to determine is the project already exists, so used client.Client().ProjectByName()

It returns:

Error getting project project-name graphql: Unauthorized: You don't have permission to "view:user" on "ssh_key": {"users":["uuid-shaped-key"]}

I changed this to use ProjectByNameExtended() and it worked perfectly. I've not really dug into this but I'm assuming it's an issue server side in GraphQL somewhere, and thought I should make you aware.

So we can remove support for default HostKeyCallback: ssh.InsecureIgnoreHostKey()