We used to be able to create GitHub personal access tokens via a request to api.github.com/authorizations with the username, password, and specifying the token’s scope. That functionality has been deprecated as of November 13, 2020.
It seems nothing took its place. They recommend the web application flow, which makes no sense if you’re building a CLI tool.
Rather than asking people to go to https://github.com/settings/tokens to manually create a new token, is there an alternative which works by not having to leave the CLI?
For that use case you should consider using "Device Flow". Documented here.
Related
I'm using GitLab Enterprise Edition 14.6.5-ee
I want to create a Git tag automatically when I merge a branch back to master. I'm fine with the actual Git commands; the problem is with the authentication: the build bot doesn't know how to authenticate back to the server. There's an answer here how to set up SSH keys. But this requires me to use my personal credentials, which is just wrong, because it's not me creating the tag; it's the build bot.
Seriously, it just doesn't make sense to say that the bot doesn't know how to authenticate. I mean, it just pulled the freakin' code from the repo! So why is it such a big leap from being able to pull code to being able to push code?
Any ideas how to automate the creation of tags without using my personal credentials?
CI jobs do have a builtin credential token for accessing the repository: the $CI_JOB_TOKEN variable. However this token only has read permissions, so it won't be able to create tags. To write to the repository or API, you'll have to supply a token or SSH key to the job. However, this doesn't necessarily have to be your personal token.
There are a few ways you can authenticate to write to the project without using a personal credential:
You can use project access tokens
You can use group access tokens -- these are only exposed in the UI after GitLab 14.7
You can use deploy SSH keys (when you grant read-write to the key)
So why is it such a big leap from being able to pull code to being able to push code?
This is probably a good thing. While it may require you to do extra work in this case, the builtin job authorization tries to apply the principle of least privilege. Many customers have even argued that the existing CI_JOB_TOKEN permissions are too permissive because they allow access to read other projects!
In any case, it is on GitLab's roadmap to make these permissions more controllable and flexible :-)
Alternatively, use releases
If you don't mind creating a release in addition to a tag, you could also use the release: keyword in the CI yaml as an easy way to create the tag.
It's somewhat of an irony that the releases API allows you to use the builtin CI_JOB_TOKEN to create releases (and presumably tags) but you cannot (as far as I know) use CI_JOB_TOKEN on the tags API to create a tag.
However, in this case, it will still have the effect that the releases/tag appear to be created by you.
I'm creating a Google Workspace Add-On and need to make some requests using OAuth. They provide a guide here explaining how to do so. In the sample code, it's suggested that the OAuth client secret be inline:
function getOAuthService() {
return OAuth2.createService('SERVICE_NAME')
.setAuthorizationBaseUrl('SERVICE_AUTH_URL')
.setTokenUrl('SERVICE_AUTH_TOKEN_URL')
.setClientId('CLIENT_ID')
.setClientSecret('CLIENT_SECRET')
.setScope('SERVICE_SCOPE_REQUESTS')
.setCallbackFunction('authCallback')
.setCache(CacheService.getUserCache())
.setPropertyStore(PropertiesService.getUserProperties());
}
Is this safe for me to do?
I don't know how Google App Script is architected so I don't have details on where and how the code is being run.
Most likely it is safe since the script is only accessible to the script owner and Workspace Admins if it is for Google workspace (which may or may not be an issue).
Well, you can add some security/safety by making use of a container, by using Container-bound script which makes use of Google Spreadsheet, Google Doc or any other that allows user interaction. Or a standalone script but also makes use of other way to connect to UI for interaction. Refer to this link for more detailed explanation on that: What is the appropriate way to manage API secrets within a Google Apps script?
Otherwise, the only way I see that you can do is store the keys and secrets in User Properties. Here's how you can do it: Storing API Keys and secrets in Google AppScript user property
Also you can refer to this link below for more general information on how you can manage or add some security: https://softwareengineering.stackexchange.com/questions/205606/strategy-for-keeping-secret-info-such-as-api-keys-out-of-source-control
I'm building a full-stack application with Next-JS. I'm building an API that works with Firebase. I was wondering if there is a way to make this API secure.
Let me elaborate. There is an option to your account called Premium. This variable is stored in the Firestore and will determine if you have purchased a Premium membership. This will determine whether or not you have access to certain features. I will use an API to change this variable.
I had the following in mind:
Have a button on the page to upgrade account.
Button pressed? Call to the API with the following params: email, upgrade to. This is because the same function can also be used to downgrade an account, for example when the user doesn't pay for the upgrade.
That API function changes the variable in the Firestore. It returns a status and a message.
I want to make option 2 more secure because otherwise, it would allow anyone to change the premium variable. That is obviously not what I want. Is there anything I can do about that? For example, a token system, the thing with that is that I have been thinking about that and I don't really know how to implement that and how it would work exactly.
For anyone wondering why I am using an API: I will also be creating an app, probably with react-native. The user will also be able to change their account status and interact with the API to do other stuff in that app.
Thanks for reading and responding! I hope this is at least a bit clear. If you have any questions, please comment them.
I do similar things in my app. I use Cloud Functions (which operate in a secure environment) to both save settings in Security-Rules -protected tables, as well as setting Custom Claims in the users Auth profile. All authorizations are then verified in the Cloud Functions before any changes are made - You may need to "seed" some values in a protected collection/document from the Console to get the process started.
I am trying to implement the clickwrap process and am using the php SDK.
When going through Auth via the Authorization Code Grant method and as part of the process it is asking for a login before completing the process. I've used my dev account details however why is this step needed as we are already passing through various keys/id?
Is this specific to the development environment or will this also happen in prod?
What will be presented to the end-user who does not have a Docusign Account?
I understand the 'obtain user consent' and can work that into the workflow but this is confusing.
I have worked through the Quickstart app as well and that has the same process. Have I misunderstood something?
If you want a page on your application to include a DocuSign clickwrap agreement, then you do not need to use the Click api. (It really should be named the Click Management API.)
What you do: follow the instructions for adding a clickwrap agreement shown in the Click User Guide.
The Click Q & A page is also helpful.
The "Click API" is only needed if you want to programmatically look up the Click agreements, modify the Click configuration, etc.
If you're just building an app that would ask for user to agree to a clickwrap using DocuSign Click, you won't need the end-user to authenticate.
I suggest you look at https://myclickwrap.sampleapps.docusign.com/myclickwrap/ and the code in GitHub.
Your app needs the creds to make API calls, but you could use JWT for example with one-time consent and your APP will not make these API calls on behalf of anyone, but just for the one user that the account uses.
All of this is the same in the developer env or production.
What I got so far is, it is possible to Authenticate with Personal Access Token and include external CI script but a cleaner approach would be to get access using $CI_JOB_TOKEN since it is more secure and restricted. I am looking into if it can be done this way -
include 'https://gitlab-ci-token:${CI_JOB_TOKEN}#raw-file-url'
I have tried to curl in this format in a dummy script job, but it fails to fetch the file.
Apparently, an external script can be imported using file API and $CI_JOB_TOKEN (https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2346/diffs), but I am looking into if include feature also support this. Any suggestion on how to achieve that is appreciated.
Unfortunately, CI_JOB_TOKEN is very limited in scope. As of today (GitLab 11.0), you can only do two things with it:
Authenticate with the GitLab Container (Docker) Registry
Authenticate to trigger a multi-project pipeline (EE only)
References:
https://docs.gitlab.com/ce/ci/variables/
https://docs.gitlab.com/ee/ci/variables/
So you cannot use CI_JOB_TOKEN to download a file from another repository, neither via the raw endpoint (/raw/<ref>/<path>) nor the API.
Unfortunately, deploy keys don't help either -- they are only for SSH.
The only workable solution I've come up with is to use a separate user:
Create a new user with Reporter role.
Create a personal access token (/profile/personal_access_tokens) for that user with api and read_repository rights.
Add this token as a secret variable in the project CI/CD settings. Call it e.g. BUILD_USER_TOKEN.
Use $BUILD_USER_TOKEN in your CI script to access the API or project files.
This is a huge hack, and I really hope to see GitLab make CI_JOB_TOKEN a first-class, read-only (?) token with rights to specified resources.
Still there is no support for the CI_JOB_TOKEN to have a useful API access. But they are working on it https://gitlab.com/groups/gitlab-org/-/epics/3559