HTTP: what is a good empty request to test authentication? - ruby

I am writing a small Ruby program that connects to a web service. The program prompts for username and password credentials, and I would like to ensure that they are correct before I proceed with other important business.
Is there any simple HTTP GET/POST request that I can send to the web server to authenticate the credentials?
Also note that I have little experience working with web services, so I also am not sure if this approach is a good idea in the first place...
EDIT here is my source code so far. I am using the JIRA Ruby gem FYI.
client = JIRA::Client.new(
username: username,
password: password,
site: 'https://foo.com/',
context_path: '',
auth_type: :basic)
puts client.request('HEAD', '/')

https://jira.foo.no/rest/api/2/search?maxResults=1
Gets the latest issue that you have rights to see. If you can't you will get a forbidden or unauthorized HTML page

Related

Setting up authentication/authorization using Traefik ForwardAuth

I'm using Docker to setup some services and Traefik 2 acts as a reverse proxy for these services.
So far I was using Basic Auth to protect the access to the services, but I'm trying to get rid of the user/pass prompt.
Looking at the Traefik's documentation, I found the "ForwardAuth" middleware which seems fine. I'm planning to use it to replace Basic Auth, but a full implementation example is not provided as an example, and I'm having a hard time trying to set it up.
So far, thanks to Traefik forward-auth, I'm successfully calling a specific URL on a remote server in charge of the authentication (this server is developped with Spring Boot by myself). I understand that if the authentication server answers 200, it means "authentication success" while another code means "authentication failure".
Yet, I'm currently unable to write the authentication code on the remote server as I don't know how to check if I must return 200 or something else. Especially I don't know how to communicate information between Traefik and the authentication server.
Basically, the problems I have are:
I can't ask the user for his/her username/password using Traefik
When the authentication server receives the request from Traefik, it has no way to define that the source request was a previously authenticated user
The following picture shows most of my concerns:
What I'd like to achieve is the following behavior:
The user tries to access to the Docker services without entering any username/password
Traefik determines that the user is not authenticated, thanks to forward-auth it asks the authentication server for authentication
The authentication server determines that the user is not authenticated, the user is redirected to the login page
The user enters his/her username/password on the authentication server
The user is redirected to the Docker services
Traefik determines that the user is authenticated
So far, I can successfully achieve step 1 to 5, but I don't know how to achieve step 6.
Is this the right way to use ForwardAuth?
If it is, are there some headers I must use to transfer the auth information? If not, is it possible to achieve what I want using ForwardAuth?
As far as i understand, traefik also forwards Any headers accompaning the original request. If you are not filtering Any. see docs traefik forward-auth.

Can't authenticate google app to read email [duplicate]

On the website https://code.google.com/apis/console I have registered my application, set up generated Client ID: and Client Secret to my app and tried to log in with Google.
Unfortunately, I got the error message:
Error: redirect_uri_mismatch
The redirect URI in the request: http://127.0.0.1:3000/auth/google_oauth2/callback did not match a registered redirect URI
scope=https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email
response_type=code
redirect_uri=http://127.0.0.1:3000/auth/google_oauth2/callback
access_type=offline
approval_prompt=force
client_id=generated_id
What does mean this message, and how can I fix it?
I use the gem omniauth-google-oauth2.
The redirect URI (where the response is returned to) has to be registered in the APIs console, and the error is indicating that you haven't done that, or haven't done it correctly.
Go to the console for your project and look under API Access. You should see your client ID & client secret there, along with a list of redirect URIs. If the URI you want isn't listed, click edit settings and add the URI to the list.
EDIT: (From a highly rated comment below) Note that updating the google api console and that change being present can take some time. Generally only a few minutes but sometimes it seems longer.
In my case it was www and non-www URL. Actual site had www URL and the Authorized Redirect URIs in Google Developer Console had non-www URL. Hence, there was mismatch in redirect URI. I solved it by updating Authorized Redirect URIs in Google Developer Console to www URL.
Other common URI mismatch are:
Using http:// in Authorized Redirect URIs and https:// as actual URL, or vice-versa
Using trailing slash (http://example.com/) in Authorized Redirect URIs and not using trailing slash (http://example.com) as actual URL, or vice-versa
Here are the step-by-step screenshots of Google Developer Console so that it would be helpful for those who are getting it difficult to locate the developer console page to update redirect URIs.
Go to https://console.developers.google.com
Select your Project
Click on the menu icon
Click on API Manager menu
Click on Credentials menu. And under OAuth 2.0 Client IDs, you will find your client name. In my case, it is Web Client 1. Click on it and a popup will appear where you can edit Authorized Javascript Origin and Authorized redirect URIs.
Note: The Authorized URI includes all localhost links by default, and any live version needs to include the full path, not just the domain, e.g. https://example.com/path/to/oauth/url
Here is a Google article on creating project and client ID.
If you're using Google+ javascript button, then you have to use postmessage instead of the actual URI. It took me almost the whole day to figure this out since Google's docs do not clearly state it for some reason.
In any flow where you retrieved an authorization code on the client side, such as the GoogleAuth.grantOfflineAccess() API, and now you want to pass the code to your server, redeem it, and store the access and refresh tokens, then you have to use the literal string postmessage instead of the redirect_uri.
For example, building on the snippet in the Ruby doc:
client_secrets = Google::APIClient::ClientSecrets.load('client_secrets.json')
auth_client = client_secrets.to_authorization
auth_client.update!(
:scope => 'profile https://www.googleapis.com/auth/drive.metadata.readonly',
:redirect_uri => 'postmessage' # <---- HERE
)
# Inject user's auth_code here:
auth_client.code = "4/lRCuOXzLMIzqrG4XU9RmWw8k1n3jvUgsI790Hk1s3FI"
tokens = auth_client.fetch_access_token!
# { "access_token"=>..., "expires_in"=>3587, "id_token"=>..., "refresh_token"=>..., "token_type"=>"Bearer"}
The only Google documentation to even mention postmessage is this old Google+ sign-in doc. Here's a screenshot and archive link since G+ is closing and this link will likely go away:
It is absolutely unforgivable that the doc page for Offline Access doesn't mention this. #FacePalm
For my web application i corrected my mistake by writing
instead of : http://localhost:11472/authorize/
type : http://localhost/authorize/
Make sure to check the protocol "http://" or "https://" as google checks protocol as well.
Better to add both URL in the list.
1.you would see an error like this
2.then you should click on request details
after this , you have to copy that url and add this on https://console.cloud.google.com/
go to https://console.cloud.google.com/
click on Menu -> API & Services -> Credentials
you would see a dashboard like this ,click on edit OAuth Client
now in Authorized Javascript Origins and Authorized redirect URLS
add the url that has shown error called redirect_uri_mismatch i.e here it is
http://algorithammer.herokuapp.com , so i have added that in both the places in
Authorized Javascript Origins and Authorized redirect URLS
click on save and wait for 5 min and then try to login again
This seems quite strange and annoying that no "one" solution is there.
for me http://localhost:8000 did not worked out but http://localhost:8000/ worked out.
This answer is same as this Mike's answer, and Jeff's answer, both sets redirect_uri to postmessage on client side. I want to add more about the server side, and also the special circumstance applying to this configuration.
Tech Stack
Backend
Python 3.6
Django 1.11
Django REST Framework 3.9: server as API, not rendering template, not doing much elsewhere.
Django REST Framework JWT 1.11
Django REST Social Auth < 2.1
Frontend
React: 16.8.3, create-react-app version 2.1.5
react-google-login: 5.0.2
The "Code" Flow (Specifically for Google OAuth2)
Summary: React --> request social auth "code" --> request jwt token to acquire "login" status in terms of your own backend server/database.
Frontend (React) uses a "Google sign in button" with responseType="code" to get an authorization code. (it's not token, not access token!)
The google sign in button is from react-google-login mentioned above.
Click on the button will bring up a popup window for user to select account. After user select one and the window closes, you'll get the code from the button's callback function.
Frontend send this to backend server's JWT endpoint.
POST request, with { "provider": "google-oauth2", "code": "your retrieved code here", "redirect_uri": "postmessage" }
For my Django server I use Django REST Framework JWT + Django REST Social Auth. Django receives the code from frontend, verify it with Google's service (done for you). Once verified, it'll send the JWT (the token) back to frontend. Frontend can now harvest the token and store it somewhere.
All of REST_SOCIAL_OAUTH_ABSOLUTE_REDIRECT_URI, REST_SOCIAL_DOMAIN_FROM_ORIGIN and REST_SOCIAL_OAUTH_REDIRECT_URI in Django's settings.py are unnecessary. (They are constants used by Django REST Social Auth) In short, you don't have to setup anything related to redirect url in Django. The "redirect_uri": "postmessage" in React frontend suffice. This makes sense because the social auth work you have to do on your side is all Ajax-style POST request in frontend, not submitting any form whatsoever, so actually no redirection occur by default. That's why the redirect url becomes useless if you're using the code + JWT flow, and the server-side redirect url setting is not taking any effect.
The Django REST Social Auth handles account creation. This means it'll check the google account email/last first name, and see if it match any account in database. If not, it'll create one for you, using the exact email & first last name. But, the username will be something like youremailprefix717e248c5b924d60 if your email is youremailprefix#example.com. It appends some random string to make a unique username. This is the default behavior, I believe you can customize it and feel free to dig into their documentation.
The frontend stores that token and when it has to perform CRUD to the backend server, especially create/delete/update, if you attach the token in your Authorization header and send request to backend, Django backend will now recognize that as a login, i.e. authenticated user. Of course, if your token expire, you have to refresh it by making another request.
Oh my goodness, I've spent more than 6 hours and finally got this right! I believe this is the 1st time I saw this postmessage thing. Anyone working on a Django + DRF + JWT + Social Auth + React combination will definitely crash into this. I can't believe none of the article out there mentions this except answers here. But I really hope this post can save you tons of time if you're using the Django + React stack.
In my case, my credential Application type is "Other". So I can't find Authorized redirect URIs in the credentials page. It seems appears in Application type:"Web application". But you can click the Download JSON button to get the client_secret.json file.
Open the json file, and you can find the parameter like this: "redirect_uris":["urn:ietf:wg:oauth:2.0:oob","http://localhost"]. I choose to use http://localhost and it works fine for me.
When you register your app at https://code.google.com/apis/console and
make a Client ID, you get a chance to specify one or more redirect
URIs. The value of the redirect_uri parameter on your auth URI has to
match one of them exactly.
Checklist:
http or https?
& or &?
trailing slash(/) or open ?
(CMD/CTRL)+F, search for the exact match in the credential page. If
not found then search for the missing one.
Wait until google refreshes it. May happen in each half an hour if you
are changing frequently or it may stay in the pool. For my case it was almost half an hour to take effect.
for me it was because in the 'Authorized redirect URIs' list I've incorrectly put https://developers.google.com/oauthplayground/ instead of https://developers.google.com/oauthplayground (without / at the end).
The redirect url is case sensitive.
In my case I added both:
http://localhost:5023/AuthCallback/IndexAsync
http://localhost:5023/authcallback/indexasync
If you use this tutorial: https://developers.google.com/identity/sign-in/web/server-side-flow then you should use "postmessage".
In GO this fixed the problem:
confg = &oauth2.Config{
RedirectURL: "postmessage",
ClientID: ...,
ClientSecret: ...,
Scopes: ...,
Endpoint: google.Endpoint,
}
beware of the extra / at the end of the url
http://localhost:8000 is different from http://localhost:8000/
It has been answered thoroughly but recently (like, a month ago) Google stopped accepting my URI and it would not worked. I know for a fact it did before because there is a user registered with it.
Anyways, the problem was the regular 400: redirect_uri_mismatch but the only difference was that it was changing from https:// to http://, and Google will not allow you to register http:// redirect URI as they are production publishing status (as opposed to localhost).
The problem was in my callback (I use Passport for auth) and I only did
callbackURL: "/register/google/redirect"
Read docs and they used a full URL, so I changed it to
callbackURL: "https://" + process.env.MY_URL+ "/register/google/redirect"
Added https localhost to my accepted URI so I could test locally, and it started working again.
TL;DR use the full URL so you know where you're redirecting
2015 July 15 - the signin that was working last week with this script on login
<script src="https://apis.google.com/js/platform.js" async defer></script>
stopped working and started causing Error 400 with Error: redirect_uri_mismatch
and in the DETAILS section: redirect_uri=storagerelay://...
i solved it by changing to:
<script src="https://apis.google.com/js/client:platform.js?onload=startApp"></script>
Rails users (from the omniauth-google-oauth2 docs):
Fixing Protocol Mismatch for redirect_uri in Rails
Just set the full_host in OmniAuth based on the Rails.env.
# config/initializers/omniauth.rb
OmniAuth.config.full_host = Rails.env.production? ? 'https://domain.com' : 'http://localhost:3000'
REMEMBER: Do not include the trailing "/"
None of the above solutions worked for me. below did
change authorised Redirect urls to - https://localhost:44377/signin-google
Hope this helps someone.
My problem was that I had http://localhost:3000/ in the address bar and had http://127.0.0.1:3000/ in the console.developers.google.com
Just make sure that you are entering URL and not just a domain.
So instead of:
domain.com
it should be
domain.com/somePathWhereYouHadleYourRedirect
Anyone struggling to find where to set redirect urls in the new console: APIs & Auth -> Credentials -> OAuth 2.0 client IDs -> Click the link to find all your redirect urls
My two cents:
If using the Google_Client library do not forget to update the JSON file on your server after updating the redirect URI's.
I also get This error Error-400: redirect_uri_mismatch
This is not a server or Client side error but you have to only change by checking that you haven't to added / (forward slash) at the end like this
redirecting URL list ❌:
https://developers.google.com/oauthplayground/
Do this only ✅:
https://developers.google.com/oauthplayground
Let me complete #Bazyl's answer: in the message I received, they mentioned the URI
"http://localhost:8080/"
(which of course, seems an internal google configuration). I changed the authorized URI for that one,
"http://localhost:8080/" , and the message didn't appear anymore... And the video got uploaded... The APIS documentation is VERY lame... Every time I have something working with google apis, I simply feel "lucky", but there's a lack of good documentation about it.... :( Yes, I got it working, but I don't yet understand neither why it failed, nor why it worked... There was only ONE place to confirm the URI in the web, and it got copied in the client_secrets.json... I don't get if there's a THIRD place where one should write the same URI... I find nor only the documentation but also the GUI design of Google's api quite lame...
I needed to create a new client ID under APIs & Services -> Credentials -> Create credentials -> OAuth -> Other
Then I downloaded and used the client_secret.json with my command line program that is uploading to my youtube account. I was trying to use a Web App OAuth client ID which was giving me the redirect URI error in browser.
I have frontend app and backend api.
From my backend server I was testing by hitting google api and was facing this error. During my whole time I was wondering of why should I need to give redirect_uri as this is just the backend, for frontend it makes sense.
What I was doing was giving different redirect_uri (though valid) from server (assuming this is just placeholder, it just has only to be registered to google) but my frontend url that created token code was different. So when I was passing this code in my server side testing(for which redirect-uri was different), I was facing this error.
So don't do this mistake. Make sure your frontend redirect_uri is same as your server's as google use it to validate the authenticity.
The main reason for this issue will only come from chrome and chrome handles WWW and non www differently depending on how you entered your URL in the browsers and it searches from google and directly shows the results, so the redirection URL sent is different in a different case
Add all the possible combinations you can find the exact url sent from fiddler , the 400 error pop up will not give you the exact http and www infromation
Try to do these checks:
Bundle ID in console and in your application. I prefer set Bundle ID of application like this "org.peredovik.${PRODUCT_NAME:rfc1034identifier}"
Check if you added URL types at tab Info just type your Bundle ID in Identifier and URL Schemes, role set to Editor
In console at cloud.google.com "APIs & auth" -> "Consent screen" fill form about your application. "Product name" is required field.
Enjoy :)

GitHub OAuth authorize request doesn't redirect to Authorize Application page

I've implemented my own classes for handling authorization via OAuth to GitHub using Faraday in Ruby. I've verified that under the following conditions:
Not logged into GitHub
No token exists for the app
that a request for authorization via GET to "/login/oauth/authorize" with a random state variable:
Redirects to the GitHub login page
Redirects to the Authorize Application page after login
Executes callback to my app with temporary code after authorizing
Responds with access_token when I POST to "/login/oauth/access_token" with temporary code
The problem I have is when I alter the first condition, I'm not already logged into GitHub. The same GET request is sent to GitHub, I see the correct URL with the right parameters. I then see what appears to be the correct redirect by GitHub with a return_to parameter, but it quickly just redirects again back to the GitHub home page.
I'm hoping it's something easy like forgetting a header parameter or something, and someone might spot the problem right away. Anyway, any help is appreciated...
Code to setup Faraday connection:
def connection
#connection ||= Faraday.new(url: 'https://github.com') do |faraday|
faraday.request :url_encoded
faraday.response :logger
faraday.adapter Faraday.default_adapter
end
end
Code to send authorization request:
def request_authorization(client_id, redirect_uri, redirect_id, scope, expected_state)
response = connection.get '/login/oauth/authorize', {
client_id: client_id,
redirect_uri: "#{redirect_uri}?id=#{redirect_id}",
scope: scope,
state: expected_state
}
if response.status == 302
response.headers[:location]
else
nil
end
end
I didn't show the code, but my controller does a redirect to the URL reply from request_authorization(). Again, I definitely see the redirect from my controller in both cases, but the second case seems to encounter something GitHub didn't like in the redirected request. I assume it then redirects to the home page and never replies to my app because of this unknown problem in my original request.
Thanks,
David
Ivan from GitHub was a great help in finding the answer to my question. I had assumed the problem was some detail with using Faraday or OAuth, but it turns out the problem was a basic assumption that proved wrong. Hopefully this will help others that run into a similar misunderstanding.
I had assumed that a user of my app that wanted to connect to GitHub (or another OAuth service) would issue something like a "connect" request to my app. My app would then generate the OAuth authorization request to GitHub, handle any redirects, and eventually wind up presenting the Authorize App page to the user for acceptance.
Turns out I just needed to make the "connect" request actually a link to directly make the authorization request to GitHub. My app then only has to worry about handling the callback, which it already did. Easier and works in all cases now.
Turns out the wrong approach worked when not logged in due to it being the simple case. It failed when logged in because I wasn't handling session state that normally the browser would provide.
A more careful read of the OAuth RFC cleared up my confusion about where requests and responses are handled for the User Agent and for the Client.

WCF over HTTPS Basic Authentication with LDAP

I'm currently working on building a WCF web Service, I was asked to use Basic Authentication over HTTPS and also to validate whether the user is present in an LDAP group for Authorization.
I searched in Internet and it is said that Active Directory Authentication is not available in IIS and we should use our own Custom Basic Authentication Module or UserNamePasswordValidator.
Link I used for coding Custom Authentication Module
I have hosted the WCF in local IIS with SSL and now it is running under https.
The question is, If I implement this one, I need to add the Authorization header manually it seems. Is there any other way I can get the User Name or Password entered in the Basic Authentication dialog which is showed when we open the service in a browser ?.
OR
could you please provide an advice on what are the things I need to do to implement the above said Security ?
I'm helpless and requesting your help on this !!!!. Thanks in Advance.
Background:
I also tried UserNamePasswordValidator, but it was doing at the Application level, I was able to view the wsdl file (Meta data of the web service without even providing credentials) so I did went with the Custom Basic Authentication Module.
With Custom Basic Authentication Module , it is asking for credentials before the svc is opened in browser. So I think this would best suite. Please provide your valuable suggestions.
Basic authentication works by the web server returning a 401.0 status code AND a WWW-Authenticate response header with the value 'Basic real="xxx"' where the realm is simply information shown to the user so that they understand what is asking for the authentication. When the browser receives this type of response, it displays a dialogue box to the user asking for a username/password. The browser then re-submits the originally requested URL, but also includes an 'Authorization' header whose value is a base64 encoded string which includes the username and password.
A custom authentication module for IIS basically has to handle this interaction. For each request that comes in, it needs to see if there is an 'Authorization' header, and if so, it extracts the username/password, authenticates them in whatever fashion it likes, and if successful sets up the Context.User. If there is no 'Authorization' header, or the username/password are not valid, then the module must set the response code to 401.0, and ensure that there is a WWW-Authenticate header (as described above).
In order to use the module, all other authentication modules in IIS must be disabled (although there seem to be some circumstances in which the anonymous authentication module should be enabled). Due to caching in IIS, don't be surprised if not all requests are passed to your authentication module.

How to deploy multiple Rack/Sinatra apps with Passenger (on Apache) with HTTP Basic Authentication?

The issue here is with multiple instances of the same Sinatra (Rack) app deployed on Passenger+Apache on different sub URIs with HTTP basic auth to keep away unwanted access:
I have 4 instances of a Sinatra app deployed on my domain as:
example.com/private/foo
example.com/private/moo
...
...
Access to all of them is protected by HTTP basic authentication using the Rack::Auth::Basic middleware. config.ru for all of them look like:
# ...
users = {'user' => 'password'}
use Rack::Auth::Basic, 'realm' do |username, password|
users.key?(username) && users[username] == password
end
run MyApp
The only thing the changes from one config.ru to another is the 'realm' parameter.
Now the issue is that once I have logged into one of the apps, say private/foo, Chrome doesn't prompt me for a username and password for other apps (private/moo etc.). This is counterintuitive since all instances are uniquiely identified by their URLs. Using different credentials for each instance does work, but shouldn't Chrome request credentials at least once for each instance? One thing I noticed is that the first time I log into one of the instances, Chrome says 'The server at example.com:80 requires a username and password'. I would have expected 'The resource example.com/private/foo requires a username and password'. Isn't that how it is supposed to work?
I checked Rack::Auth::Basic source code and Wikipedia's article on HTTP Basic Auth and came up with nothing to help my case :(.
In basic authentication, the realm parameter isn't send back to the server. So the server can't really check if the client is sending authorization header for the same realm or not. It depends on the client. Rack's implementation of HTTP basic authentication is correct. So:
Now the issue is that once I have logged into one of the apps, say private/foo, Chrome doesn't prompt me for a username and password for other apps (private/moo etc.). This is counterintuitive since all instances are uniquiely identified by their URLs.
As Andrew pointed out and is clear from the RFC, URL doesn't play a role there. But if '/foo' is protected, '/foo/moo' is protected under the same realm.
Using different credentials for each instance does work, but shouldn't Chrome request credentials at least once for each instance?
Under the scenes what is happening (on inspecting with debugger tools) is that, after I have logged once into one of the apps, say private/foo, Chrome re-sends the same authorization header to other apps, say private/moo, without being challenged first.
The RFC says that the client may send the corresponding authorization header for a realm without being challenged by the server first.
Looks like Chrome is either treating all my apps to be under the same realm or re-sending the same authorization header across different realms. I don't think that is the expected behavior but I could be missing something. Firefox behaves same. Anyway, that wasn't the essence of the question.
The theme of the question was "How do I get Chrome to request me username and password at least once for each instance? Basic auth isn't working the way I expected it to; why?"
Use Digest authentication (RFC 2617 again). Rack implements the MD5 algorithm version under Rack::Auth::Digest::MD5. Set different opaque for each instance and you are good to go:
# ...
realm = "Description of the protected area."
opaque = "Secret key that uniquely identifies a realm."
users = {'user' => 'password'}
use Rack::Auth::Digest::MD5, realm, opaque do |username|
users[username]
end
opaque is sent back by the client and can be verified on the server side that the authorization request is for the correct resource. Job of realm seems descriptory in nature -- which area or resource are you trying to protect? what id do I flash?
RFC: https://www.rfc-editor.org/rfc/rfc2617

Resources