I'm running GitLab on local address http://192.168.0.18/. Upsource is running on http://192.168.0.11/.
I've added Upsource application as admin on GitLab. I've set client id and secret token as GitLab said. Authorization is set to http://192.168.0.18/oauth/authorize, token to http://192.168.0.18/oauth/token and user data to http://192.168.0.18/api/v4/user (according to GitLab documentation). In field mappings, I've set User ID to "id" and both e-mails to "email".
Then, on logging page of Upsource, I've oath authentication icon. After clicking on it, GitLab requires logging and user has to authorize application for its account:
Authorization required
Authorize Upsource to use your account?
You are an admin, which means granting access to Upsource will allow them to interact with GitLab as an admin as well. Proceed with caution.
This application will be able to:
Access your API
Read user information
Hovewer, after clicking authorize button, Upsource displays info: Authentication failed. Check your credentials and try again.. What have I set wrong? Field mappings?
Oh, I've found the answer. As happens often, I was fighting with this a good amount of hours and just after I asked this question, I've got idea to run this on my own. Rubber duck method, I guess...
As I suspected, the problem was in field mappings.
I looked in Network tab in Chrome and there was this response:
http://192.168.0.11/hub/auth/login?response_type=token&client_id=[CLIENT_ID]&redirect_uri=[REDIRECT_URI]&message=hub-auth-failed&developer_message=getValueByPath%28json%2C+aut%E2%80%A6userIdPath%29%21%21.textValue%28%29+must+not+be+null
I've manually went through all Gitlab workflow and then I could log in - and after running http://192.168.0.18/api/v4/user endpoint, I've got user data:
{"name":"username","username":"username","id":3,"state":"active","avatar_url":"http://www.gravatar.com/avatar/94232f2d1f8bb2fe940de439a4df1014?s=80&d=identicon","web_url":"http://debian/username","created_at":"2017-03-25T22:28:21.375Z","is_admin":true,"bio":null,"location":null,"skype":"","linkedin":"","twitter":"","website_url":"","organization":null,"last_sign_in_at":"2017-03-25T22:28:21.487Z","confirmed_at":"2017-03-25T22:28:21.376Z","email":"username#username.username","color_scheme_id":1,"projects_limit":100000,"current_sign_in_at":"2017-03-25T22:36:31.853Z","identities":[],"can_create_group":true,"can_create_project":true,"two_factor_enabled":false,"external":false}
The problem was in setting ID field name. As we can see in above JSON data, id field should be mapped to name/username, not id itself.
After this change I could sucessfully login into Upsource.
Related
I would like that the users of my app can login through the gitlab without the user need configurate nothing, like many apps of the web, you only click in allow and is logged. Because I need use the gitlab api to create repositories, make commits, and pull requests in their accounts. I read this:
https://docs.gitlab.com/ee/api/oauth2.html#implicit-grant-flow
I need that be "implicit-grant-flow", because I don't want send nothing for the server, all thing should happen in the client app. I think that is it because I read:
"Implicit grant flow: This flow is designed for user-agent only apps (e.g., single page web application running on GitLab Pages)."
But I also read:
https://gitlab.example.com/oauth/authorize?client_id=APP_ID&redirect_uri=REDIRECT_URI&response_type=token&state=YOUR_UNIQUE_STATE_HASH&scope=public+write
APP_ID? So, the client need register the app in the gitlab account settings, ins't? But I don't want that the user have the work, I already login in the some web app using github by example, without need configurate nothing in my github account, I need the same here.
YOUR_UNIQUE_STATE_HASH? what?
I already created the gitlab application in:
https://gitlab.com/oauth/applications/
But I can't see nothing about "YOUR_UNIQUE_STATE_HASH" there.
I don't understand how this can be a login button that allow me to use the gitlab API to make a commit in name of the user for example.
Note: off course, I'll search about what should be "YOUR_UNIQUE_STATE_HASH" now.
1 - Register one app in:
https://gitlab.com/oauth/applications/
2 - Login the gitlab with:
https://gitlab.com/oauth/authorize?client_id=CLIENT_ID_THAT_YOU_REGISTRED_IN_THE_STEP_1&redirect_uri=YOUR_APP_URL_HERE&response_type=token&state=YOUR_UNIQUE_STATE_HASH
The "YOUR_UNIQUE_STATE_HASH" you can can leave with this.
3 - If you got success, you'll be redirect and the access_token is in the url.
4 - Test the gitlab API:
https://gitlab.com/api/v4/projects?access_token=THE_ACCESS_TOKEN_THAT_IS_IN_THE_URL
You also can get the token and clean the url like:
function getToken() {
const url = new URL(window.location.href.replace(/#/g,"?"))
const token = url.searchParams.get("access_token")
const urlWithoutParams = url.href.split('?')[0]
window.history.replaceState({}, null, urlWithoutParams)
console.log(token)
}
To create a button is simple, you can create a login button like this:
<button onclick="window.location.href='https://gitlab.com/oauth/authorize?client_id=CLIENT_ID_THAT_YOU_REGISTRED_IN_THE_STEP_1&redirect_uri=YOUR_APP_URL_HERE&response_type=token&state=YOUR_UNIQUE_STATE_HASH'">Gitlab Login</button>
Warning, with GitLab 13.11 (April 2021)
GitLab OAuth implicit grant deprecation
GitLab is deprecating the OAuth 2 implicit grant flow as it has been removed for OAuth 2.1.
Beginning in 14.0, new applications will be unable to be created with the OAuth 2 implicit grant flow.
Existing OAuth implicit grant flows will no longer be supported in 14.4. Please migrate existing applications to other supported OAuth2 flows before release 14.4.
Deprecation date: June 22, 202
I have followed the documentation for creating a G Suite Service Account. The following works fine to emulate a given user in my domain:
def create_directory_service(user_email):
credentials = ServiceAccountCredentials.from_json_keyfile_name(
SERVICE_ACCOUNT_FILE_PATH,
scopes = SCOPES)
credentials = credentials.create_delegated(user_email)
return build('admin', 'directory_v1', credentials=credentials)
However, I want to be able to just use the service account to access domain information without needing to emulate a particular user. But if I pass in the service account's email address (as given in its key file), I just get HttpError 503: "Service unavailable. Please try again".
I've added the service account's email address as a Service Account Admin, but it still doesn't work. Again, delegation works fine, but not using the service account directly.
Does anyone know what I'm missing?
To use Directory API, you must use delegation to impersonate a user in the domain, that can use Directory API (so usually an admin).
How do I test the Google OAuth 2.0 on my app with localhost, since Google requires a top private domain as the authorized domain?
I tried to look up solutions, but all the solutions given have been a while ago, and I think Google has changed their service since then.
localhost is not a valid top-level domain, and it won't let you generate credentials without setting up a consent screen. You can add more than one authorized domain if you'd like, but you can't leave it empty. But you CAN delete the field if you have no domains / would not like to add domains for now. you just can't LEAVE it empty.
Notice the description -- "When a domain is used". so it's not an obligation to add authorized domain for consent screen. Moreover, the authorized domain here is only related with consent screen. Authorized origins and Authorized redirect URLs needs to be specified in the credentials part, which is all that matters; specifying the origin from which requests will be accepted and where it will be redirected. So just omit the authorized domain in the consent screen.
So how to delete it? Just in case if you haven't noticed, just hover over the field and this little man will pop up. delete it. that's all. Now you should be able to save and continue, where it might ask you to setup scopes.
I know it's really late, hoping it might help others..
After about an hour banging my head against the wall I found this article that has a step by step solution that works (as of July 2020).
Basically you need to create a service account, share the sheet with that account, and then it should work.
All of the other auth methods I tried either raised nonsense errors, or simply silently didn't work.
The list of authorized domains is required before you submit a request for app verification. If you want to configure a localhost redirect URI, that is configurable in your web OAuth client ID configuration.
In case anyone has struck out on the suggestions above, this answer did the trick for me. Set my authorized JavaScript origins URI to http://localhost:8080 in the google API console then emptied my Chrome cache.
Just add an OAuth-consent-screen from here without a domain or valid domain that's up to you, after that create Credentials from here, then select OAuth client ID and enter your from here you can add javascript origin url and there you go you've done.
You add your final domain for when you are ready to become verified. Until then you will generate an OAuth client ID and enable https://localhost:3000 in "Authorized JavaScript origins"
Simple screenshot of the field you can enter localhost
Not beautiful, but works!
I've made local website(domain) on Xampp like test1.com, added that domain in Authorized domains and started Chrome from separate shortcut with parameter --ignore-certificate-errors
Note, that when you start with this flag, Chrome must not be running!
It cause Chrome to open web site in the xampp\htdocs folder and I was forced to go to folder test1.git and then to public folder, where finally site opened and the url was: https://test1.com/test1.git/public
ps. Use port 80 in httpd-vhosts.conf and not 443!
I have a Bitbucket repository, which I'm able to logging in web browser with my credentials, Now I want to checkout it in Sourcetree, So I've installed Sourcetree 2.6.10, It requires authentication to Bitbucket server with Root URL & Username to continue, I'm providing input in below format...
Root URL : https://bitbucket.xxxxxxx.com
Username : xxxxxx.xxxxxx
The error i'm getting is...
Failed to check login for user [xxxxx.xxxxxx]. You do not have permission to access URL ‘https://bitbucket.xxxxxxxxx.com/rest/api/1.0/users/xxxxxx.xxxxxx’ please check the user credentials associated with this account. The request returned with status code ‘Unauthorized’.
Any help would be appreciated, thanks !
To fix:
1-go to source tree window, clicked remote
2-little gear icon, clicked "settings"
3-double clicked on Bitbucket server, changed protocol from default HTTPS to SSH
To Perforce, Now, I m sharing another solution whether if the user prefers, BitBucket Cloud intergrated with SourceTree,(facing the above stated issue),
Since one of the steps of the upgrade process was to input your Atlassian account password, you should now have a password set (in addition to being able to use Google). You should be able to use your Bitbucket username and Atlassian account password to authenticate SourceTree.
If you need to reset your Atlassian account password, you can do so here: https://id.atlassian.com/login/resetpassword
Source : https://community.atlassian.com/t5/Bitbucket-questions/Cannot-login-with-Bitbucket-in-SourceTree-after-linking-with/qaq-p/145231
I had a similar problem trying to register Sourcetree the first time I opened it, using my company's Bitbucket Server URL. Turns out I just needed to include https:// at the beginning of the URL.
Drop everything after ".com" and log in there.
e.g. log into
https://bitbucket.xxxxxxx.com
not
‘https://bitbucket.xxxxxxxxx.com/rest/api/1.0/users/xxxxxx.xxxxxx’
see also
https://jira.atlassian.com/browse/SRCTREEWIN-8743
I'm just getting started with D2L and am running into problems.
On the "Getting Started" page, I have completed the first three steps:
1) Acquire an App Key/ID pair from D2L - I have received the App ID and App Key
2) Create a test account in your host LMS - I have created a new user account with the administrator role for testing
3) Choose a client library to work with - I am using the PHP SDK
4) Authenticate with your LMS - This is where I'm running into trouble.
When I use the Getting Started sample:
http://samples.valence.desire2learn.com/samples/GettingStartedSample/
And enter my host, app ID and app key and hit on the "Authenticate" button, I get a "This application is not authorized on this LMS instance. Ask your administrator to authorize this application" error.
I am an administrator on my D2L host and I'm not sure how to authorize my own app.
I have tried the following:
Navigating to the "Manage Extensibility" page because that's where D2L says my app should be located, but it isn't there.
Enabling the API (d2l.Security.Api.EnableApi) under the "DOME" page to no avail.
What am I doing wrong?
Based on your question and comments, there were two issues here:
First is that the list of App ID/Key pairs appropriate for your LMS get regularly fetched by your LMS from the D2L KeyTool service. The schedule for this fetching is once a day; accordingly, if the scheduled task isn't set up, or if your LMS isn't identifying itself properly to the KeyTool service, or if time hasn't yet elapsed after key granting to the next scheduled run of the task, the App won't yet be in your LMS' Manage Extensibility list. It sounds like you no longer have that issue.
Second is that the Valence Learning Framework APIs' authentication process (requesting and retrieving a set of user tokens for an LMS user) requires several LMS features to be properly set up: (a) the LMS must be configured to support Deep Linking, (b) the LMS must be set up to handle the ?target= parameter on incoming client URL requests, and curate that parameter throughout the user authentication process.
In cases where your LMS is not doing the user authentication but depending upon another, third-party IDP (like Shibboleth), any ?target= parameter passed into the login process must be taken care of by the IDP and properly handed back to the LMS after user authentication. In a situation where you have multiple redirections occurring during user authentication, this can involve successive generation of a target parameter, and each generation must re-URL-encode the previous request URL in its entirety (like sticking an envelope inside another envelope, inside yet another envelope).
If your LMS is not properly configured to support these two points, which you might not notice during other operations, then client calls to the Learning Framework APIs won't work because the calling client won't be able to fetch back a set of user tokens.
To solve the second of these issues, you may have to contact D2L's Customer Support desk -- they can verify, and adjust as necessary, the LMS configuration part of this authentication chain. If you're integrating your LMS with other third-party IDP components not administered or deployed by D2L, then you might also need to adjust their configurations: D2L can likely advise on what needs to be done there (curate the target parameter on URls), but cannot adjust the configuration for you in those cases.