The first time we run hub, it asks for our Github username and password. This is never stored. Instead, hub uses it to create a personal access token that gets saved in your account and then it uses that token for subsequent uses.
Is there a way to achieve the same from a bash script, without registering an application and all that?
This script will be public.
without registering an application
Not exactly, since it is part of the oauth workflow.
But from a simple shell, you can store your GitHub username and password in a credential helper like libsecret (Mac) or manager (Windows).
In that case, you won't have to enter said credentials again and you don't have to register anything directly on GitHub.
Related
I am building CLI based application in golang for automation purpose for which I will be using cobra. Here user needs to login by supplying id, password and server name then golang will return client object and then that returned object will be used to call its corresponding methods. eg:-
during startup user types:-
app login --username="name" password="pwd" --server="https//someName.com"
now this login I want to retain and for subsequent commands I want to use the current session to run other commands of user
eg:- (here I dont want to authenticate user again)
app create user --username="user2"
If system is restarted then I want user to authenticate first then fire their commands
I want to follow similar behavior as followed in azure-cli
I am creating a win32 application in C++. The user will need to login with username and password. These will be used to authenticate to a web server and then the application will communicate with the web server. I would like the user to only need to input credentials the first time opening the app by having the username and password saved somewhere. How should I accomplish this? I could just save it in some plaintext file. But it looks like from searches that there is something called DPAPI? I'm not sure what is appropriate for my use. This is my first time creating a win32 application.
On apps like twitter and snapchat, if you changed the password from the web, it wouldn’t allow you to get into the app without re-authenticating with the new password. When changing your password with Parse Open Source Framework, does it implement this functionality automatically on mobile or would the developer need to implement it themselves?
You have to do it by yourself. Check the following tutorial, section Handling an Invalidated Session:
https://parse.com/tutorials/integrating-facebook-in-android
I am using Google Admin SDK Directory API to create users and using Service account I am able to perform CRUD operations on them.
I have a requirement whereby I have to check the credentials of users created using SDK.
When you fetch the users the password is not returned, hence comparison cannot be done.
I'll really appreciate if someone lets me know what would be effective way of approaching the checkCredentials function.
Thanks.
Google does not ever return the value of the password. That would be a monumental security risk.
See their documentation in regards to the user resource used in the directory API. It specifically states that the password field is never returned. It can only be used for setting the password.
If your requirement is too check creds on a newly created user, you should look into trying to login as the user with the password you just sent, using the google auth Apis
At the moment, the only solution I've found is to simulate the user login flow with a fake browser (Apache's httpcomponents-client for Java for example) pointing to Google Account ServiceLogin.
I want to run automated scripts to read files from a Dropbox folder on our server. I started looking into the dropbox gems that are out there, and they all seem to require the user to authenticate a session by opening a browser. This obviously doesn't make sense for an automated task. Is there a way to do this without requiring a user to actually open the browser manually?
The reason that they all require a web browser is that Dropbox uses OAuth v1. There is a way around this that may not be 100% in spirit with the Dropbox API T&C.
I would start by creating a Dropbox account that will be the user account you use from the scripts. Manually login as this user and go to the authorization URL for your app and approve it.
In your scripts you'll create an HTTP connection that uses that user id and password to login. You'll need to keep the information in the response that describes the user's session. Use the session information to create a second HTTP connection to the authorization URL. Since the app is already authorized, you'll just need to capture the session token from the redirect URL.
The definite downside to this is that the password for the user is in your script. :P