I'm not able to publish a package for an authenticated user by using the username:password as an API key, as long the anonymous user does not have at least the "Feeds_ViewFeed" right.
But I don't want to have my packages visible for anonymous users. But I need to publish packages by an authenticated user.
Tested with the following configuration
ProGet is hosted by the windows service
Anonymous has no rights assigned
If I try to push a package I get the following error:
Pushing xxx to 'xxx'...
Please provide credentials for: xxx UserName:
Cannot prompt for input in non-interactive mode.
Tried as well to give the anonymous user the "Feeds_AddPackage" right and protect the feed by an API key. Doesn't work either without the "Feeds_ViewFeed" assigned to anonymous. As soon as "Feeds_ViewFeed" is assigned pushing with an API key works as well.
Is this by design, configuration error or a bug?
Any advice?
Product: ProGet
Version: 3.5.5
Related
Can't login using Google Auth,
Error 403: org_internal
This client is restricted to users within its organization.
Go to cloud console (https://console.cloud.google.com/apis/)
APIs and services
Credentials
Oath consent screen
Ensure Application type is set to "public" and not internal.
Obviously assuming that you are creating an app that should be accessible outside your org. If this is related to testing and phones, it is possible to create testusers that are excepted from company policy rules.
The reason for this error is indeed because the Application type is set to "internal".
But setting it to public is not always the right answer...
Add "&prompt=select_account" to the authentication url. This will force the user to select the correct (organization-)account.
Without the parameter, Google tries to show the consent screen for the logged in Google-account, but as it is not an organization-account it will just display the 403 page without giving the user this choice.
https://developers.google.com/identity/protocols/OpenIDConnect#prompt
I had an Internal app that I was trying to authenticate with one of our YouTube channels using an organization account, and I was getting the same error:
Authorization Error
Error 403: org_internal
This client is restricted to users within its organization.
After contacting Google Workspace Support, they asked me to Change the restriction on it from Limited to Trusted.
Steps are mentioned in this support thread: https://support.google.com/a/answer/7281227
Open the Google Admin Console.
From the sidebar menu, choose: Security → API Controls.
Click on MANAGE THIRD-PARTY APP ACCESS button.
Hover the cursor over the required app and click on Change access.
Choose the option: Trusted: Can access all Google services
And save the CHANGE.
Once you've done, take note that there will be 24 hours of propagation on it before it gradually takes effect.
Make sure, for the browser you are using, that you have logged out of "All" Google account(s). This should force the "select account" windows to display.
We have almost exactly the same problem while trying to configure WP Mail SMTP for Wordpress.
The OAuth Client's Application Type has to be "Internal" so changing it to "External" was not an option for us.
Hope this helps.
I had the same issue and in my case was because the project didn't had a support email address set it.
I fix it by adding one on the Firebase Console > Project Settings > General under the Public settings section.
This error is most likely due to the configuration of your application in Google Cloud Platform.
Setting your application to "internal" is causing this error. Try making your app "external" in the OAuth consent screen, but make sure it is in a "testing" status. Then, add yourself to the test users. This configuration will work well for an internal, lightweight application.
Once complete, try to authenticate with the channel again.
I had the same issue with a project. The error only appeared if I tried to log in to my app while already logged in with an account outside the organization (worked just fine while logged out of all accounts, or while logged in with an internal organization account). I had to change the OAuth Client's Application Type from Internal to Public in the Google Dev Console.
More info can be found at https://support.google.com/cloud/answer/6158849?hl=en
Maybe you have another google email to login, not the correct one.
I am using the R packages googleAnalyticsR and googleAuthR to connect to GA and get data from it. However, every time, I run the function ga_auth() it open a web windows and ask me to verify my account. This is not convenient for someone else to use my account. I am think that whether or not there is a way I can set up my account email and account password in some R function, so that it won't ask someone else about my credentials. BTW, I don't want to use client_id and client_secret but only my GA account email and password. Is there a way to accomplish this?
When you run ga_auth() it will create a cache file in the same directory (called ga.oauth in the latest 0.5.0 version, .httr-oauth in the earlier versions)
If you make that file available to your work collegeus, then they can use your credentials, without needing to provide their own and go through the authentication flow.
You can either send them a copy of the ga.oauthfile or rename it and then tell it to be used by passing it in the first argument e.g. ga_auth("my_custom_file.oauth")
If you would like it to be more hassle free, if you have access to the system the users will be using, then setup an environment argument that points to the custom cache file. You can achieve this using the .Renviron file that is placed in the user's home directory. Then set the path to the authentication file to the GA_AUTH_FILE argument, e.g.
GA_AUTH_FILE="/Users/mark/dev/auth/ga.oauth"
Once that is setup, then when you load the library e.g. library(googleAnalyticsR) it will auto-authenticate with that auth file.
There are some more details on that in the setup section of the googleAnalyticsR website.
I created a Microsoft Account using my work mail.
Using this account, with 50$ credit, i tried to register my bot (already published using visual studio 2017). The problem is that when i tried to obtain the credentials for my bot, i'm getting an error that says i don't have enough privileges (even though i'm supposed to be the administrator of the account)
Button i clicked to get credentials
Error image
Please log into http://aad.portal.azure.com and go to Users and Groups -> User Settings and check if Users Can Register Applications is set to Yes.
Is there a way to lock a user's account after a certain number of failed login attempts to the API Store and API Publisher? I already check at FAQ API Manager, but then the documentation redirect to Identity Server files.
Its there any method on how to solve this issues?
Thank You.
You can change the following properties in APIM_HOME/repository/conf/identity/identity-mgt.properties file.
Authentication.Policy.Account.Lock.On.Failure.Max.Attempts
Authentication.Policy.Password.Expire.Time=0
# If account verification is not enabled, following property will decide where user must be lock or not after user is created
Authentication.Policy.Account.Lock.On.Creation=false
Authentication.Policy.Account.Lock.Time=0
Authentication.Policy.Account.Lock.On.Failure=false
Authentication.Policy.Account.Lock.On.Failure.Max.Attempts=0
You should first install following Identity Feature in WSO2 API Manager.
Account Recovery and Credential Management
version : 5.7.5
Then you will get the identity-mgt.properties file in your /repository/conf/identity directory.
By changing the following property value to the preferred number you can achive the account locking after several attempts.
Authentication.Policy.Account.Lock.On.Failure.Max.Attempts=0
Note :
To install the above feature,
Login to Management Console of API Manager 2.1.0 (httpso://localhost:9443/carbon)
Go to Configure > Features > Repository Management and add the following repository.
http://product-dist.wso2.com/p2/carbon/releases/wilkes/
Then search for "Account Recovery and Credential Management Feature".
Select and install the version 5.7.5 as below.
Restart the Server.
I'm building an installed application that will have features requiring the Google Drive REST API using Qt and C++. I understand Qt is now releasing new libraries to support OAuth flows but let's assume I'm a student and learning to use OAuth at this layer is a requirement for this project.
In my application, I have a working OAuth flow for installed applications that ends with an Access Token and Refresh Token being stored using QSettings (I'm open to input on whether this is a disastrously bad idea too). The application requires no authentication/login for its own sake/data, but it does need authentication to Google for calling API's using an Access Token. This application has no associated web backend being hosted; its simple and should be deployable completely locally (I've written and included a simple TCP server that will receive the authorization redirect_uri and will run and close when called from within the application).
As such, I'm curious about the best way to make sure that, when a user opens my application and wants to use the Google Drive features, they are appropriately authenticated on Google's end. Say, if I maintain an access token in the registry, and this access token is granted per-user/per-application basis (right?), then how can I make sure only the user the token belongs to is able to make calls to the API with it?
Here's my understanding and approach; feel free to correct me or educate me if I've got the wrong interpretation.
If an Access Token is found, perform the following:
Open a browser page to a Google login domain and have the user authenticate there (this could prohibit a user from being able to use a cached login session that would have access to a token they otherwise shouldn't have access to)
If user has correctly authenticated with a Google account, return control to the application and make a test call to an API using the stored token.
If the call fails (responds with an invalid_credentials) I should be able to be sure its because the access token has expired and the application will go through the flow to renew an Access Token from a Refresh Token.
If no Access Token is initially found:
Start a normal OAuth installed application flow
Get the tokens and store them so that when the user opens the application next time the former procedure is used
My issue then is the first two steps if the Access Token is found. Nominally this could be done by the typical OAuth flow but it appears that when using a localhost as the redirect uri, Google will always prompt for consent, regardless of settings for prompt and access_type authorization query parameters.
What can be done to accomplish these first two steps in a way that my application can control (i.e. not a solution that relies on a backend server being hosted somewhere)?
If this question is too open-ended for SO requirements I can make some more restrictions/assumptions to limit the problem domain but I'd rather not do that yet in case I unknowingly rope off a good viable solution.
Thanks for reading! Sorry if its a verbose; I wanted to ensure my problem domain was fully fleshed out!
If you are using an installed application, I wouldn't recommend using or storing refresh tokens. Storing refresh tokens on the client side means that if an intruder gains access to the client's application, they have infinite access to the user's application without ever having to enter the user's credentials. If you do insist on having a refresh token, ensure you follow the Google's installed app flow, with the code_verifier parameter included in your requests.
If the access token is found, you should try to verify it, and if verified then use it at the google api, otherwise force the user to login again (or refresh it if you chose to still use refresh tokens).
If no access token is found, your flow sounds fine.
A few notes on loggin in with Google:
Google will only return a refresh token if you specify access_type=offline in your auth request.
Google will only return a refresh token on the user's first authorization request, unless you always specify prompt=consent in your query params.
In my experience, when leaving out the prompt query param, the user is not prompted for their consent again. If they are logged in to google, you will get a new access token, but no refresh token, unless you have prompt=consent.
I think the idea is you use prompt=consent if you have no record of the user ever using your application. Otherwise if they have used it before, you may prefer to use prompt=select_account to allow the user to select which account he wants to use in case he has more then one, or you can just use prompt=none.
This is just my understanding of it all.
My approach I ended up using was just to deploy with an SQLite db that will be stored in the AppData roaming directory. The db schema includes a field for the user's Name (from the OpenID IDToken field if it exists), the user's picture URL (again from IDToken if it exists), the refresh and access token strings (will be stored as encrypted strings when I get around to it), the user's UID/sub string, and a field for a user name and password.
These latter two fields are authentication fields for within my own application, which, again, I wanted to avoid but it seems impossible to do so. So the user will be prompted to enter a username and password into a form, and these credentials will be checked against the existing SQLite db file mentioned previously.
If they exist and are correct, the user gets logged in and will have access to their respective access and refresh token.
If the user has forgotten their password, they'll be asked for reconsent (going through the installed app flow again), and whatever password they provided during initial login will be used as the reset password. It is considered, for my purposes, that logging into Google for the installed app flow is proof enough that the user account belongs to them and they should have authorization to reset the password.
If the user is a new user and doesn't have a record in the local SQLite db file, then they can also click a button to "Create New Account" - which effectively goes through the authorization flow as well but this time a whole new record is posted to the SQLite db with the appropriate fields filled.
There's still more optimization that could be done but at least I am getting closer to the level of security and control of access to Google user accounts that I want.
I'm not marking this as an answer because I feel like this solution is still not desired and that there should be an easier way. So if someone has evidence or experience of providing an equivalent level of authentication control without needing to maintain a local user account database then I would be more than happy to mark such a method as the solution!
Thanks again!