401 Unauthorized error in Rails two-legged OAuth provider - ruby-on-rails-3

I'm trying to implement a two-legged OAuth provider on Rails.
I followed these instruction for installing the consumer and provider:
https://github.com/pelle/oauth-plugin
with these instructions to make the consumer work
Rails3 - oauth-plugin problem
These instruction to implement the user login
https://github.com/plataformatec/devise
And used these methods to test the connection
http://oauth.rubyforge.org/rdoc/classes/OAuth/Consumer.html
Followed these instructions for implementing the two-legged strategy
Rails two-legged OAuth provider?
But on the consumer side I get
Completed 500 Internal Server Error in 86ms
OAuth::Unauthorized (401 Unauthorized ):
oauth (0.4.7) lib/oauth/consumer.rb:216:in `token_request'
oauth (0.4.7) lib/oauth/consumer.rb:136:in `get_request_token'
...
and on server side
Started POST "/oauth/request_token" for 127.0.0.1 at Sun Jan 06 22:02:08 -0300 2013
Processing by OauthController#request_token as */*
Rendered text template (0.0ms)
Filter chain halted as # <OAuth::Controllers::ApplicationControllerMethods::Filter:0x1111e0e80 #strategies=[:two_legged], #options={:interactive=>false, :strategies=>:two_legged}> rendered or redirected
Completed 401 Unauthorized in 3ms (Views: 2.1ms | ActiveRecord: 0.0ms)
This post seems to point to the same issue
https://github.com/pelle/oauth-plugin/issues/106
I'm using two-legged implementation to allow login to my rails app from my native android app.
This post seems to be related with my problem
Rails Oauth: unable to get request_token, filter chain halted
I don't know where to look or how to get a more detailed log on the server side.
Any help will be appreciated. Thanks!

Related

Why am I getting multiple response codes to one authentication POST request?

I'm working with an API and recently something went wrong with the authentication.
The API uses jwt authentication, and when POSTing the client jwt request, instead of getting back an auth jwt, I'm getting a 401 (final) status code (or 404, depending on the library I use to handle requests...), but I'm also getting 407 and 200 when setting a verbose traceback?
I'm pretty new to handling HTTP requests so I'm curious how exactly that might be happening, where are those additional two status codes coming from?

Jakarta and Glassfish - Basic authentication works, Form authentication do not

I am pretty new into web development. Currently I am trying to do an Form Based Authentication on my Jakarta app. I managed to create a realm on Glassfish 6.0.0 and to integrate it on the web.xml descriptor. I managed to make the Basic Authentication work, but when I try it to change to Form Authentication I get an 403 status code ever time I want to login. I got the following error every time I send a POST request to j_security_check with good credentials, along with 403 status code:
***WEB9102: Web Login Failed:
com.sun.enterprise.security.auth.login.common.LoginException
: Login failed: Security Exception*** which doesn't say to much for me.
I wanted to create an Form Authentication in order to use j_security_check to login using form-data format from Postman. If I can not do this, is there a way to create a custom endpoint to send a request in order to authenticate?
I found out a method to do what I needed for the moment. I just sent parameters in URL. For now it is perfect, even though the security suffer with this method.

JIRA CLI Commandline Not Authenticating With Password Federation

I'm having a few problems getting this JIRA commandline to work:
C:\tools\atlassian-cli-7.8.0>jira.bat --debug --verbose --options
basicAuthentication --server "https://jira01.COMPANY.com" --user
FIRST.LAST#COMPANY.COM --password PASSWORD --action getServerInfo
It connects to the JIRA server, but gives this error:
org.swift.common.cli.CliClient$RemoteDisallowedException: User
'FIRST.LAST#COMPANY.COM' is not allowed to log in at this point in
time perhaps due to CAPTCHA requirements or too many failed login
requests.
This error always occurs despite the fact:
JIRA Web > Profile > Username is what I'm using to log in.
JIRA Web >
Profile > Groups is jira-software-users
The password provided to the
commandline is indeed the one that works when I login via the web.
I
have tried this both with and without --options basicAuthentication
This occurs regardless of how many times I successfully log out / log
in to the JIRA web UI.
Whenever I go to JIRA Web > Profile > Change
Password, it says: "Too many incorrect login attempts: Please log out
and log in again to access this function." (This also occurs
regardless of how many times I successfully log out / log in to the
JIRA web UI.)
A CAPTCHA is never shown on the JIRA Web UI's login.
NOTE: When we login to JIRA web ui, our company appears to defer to
federated authentication via "https://login.microsoftonline.com" into
which we provide the credentials we're providing the script, which
then takes us into JIRA.
Questions:
How to get the commandline tool / jira server to accept the same credentials the jira web ui does?
Is this a permissions issue or something involving the password federation?
Suggestions for how to get this to work?
How to get it to actually clear the "too many incorrect logins" issue?
Cheers & Thanks!
-Roberto
Full trace of command is:
URL requested:
https://jira01.COMPANY.com/rest/org.swift.jira.cli/latest/validatelicense
Request type: GET Content type: application/json options:
basicauthentication URL requested:
https://jira01.COMPANY.com/rest/auth/1/session Request type: POST
Content type: application/json Using basic authentication. Request
property X-Atlassian-Token, value: [no-check] Request property
Content-Language, value: [en-US] Request property Content-Type, value:
[application/json] json: {} Problem determination - response: 403:
null Problem determination - response url:
https://jira01.COMPANY.com/rest/auth/1/session Problem determination -
request url: https://jira01.COMPANY.com/rest/auth/1/session Problem
determination - response data:
Forbidden (403)
...
Remote error: User 'FIRST.LAST#COMPANY.COM' is not allowed to log in
at this point in time perhaps due to CAPTCHA requirements or too many
failed login requests. Go to the user interface and login to clear the
problem.
org.swift.common.cli.CliClient$RemoteDisallowedException: User
'FIRST.LAST#COMPANY.com' is not allowed to log in at this point in
time perhaps due to CAPTCHA requirements or too many failed login
requests. Go to the user interface and login to clear the problem. at
org.swift.jira.cli.helpers.AuthenticationHelper.login(AuthenticationHelper.java:196)
at
org.swift.jira.cli.helpers.AuthenticationHelper.login(AuthenticationHelper.java:157)
at
org.swift.common.cli.helpers.DefaultAuthenticationHelper.handleCookies(DefaultAuthenticationHelper.java:124)
at
org.swift.jira.cli.JiraClient.getAuthenticationHelper(JiraClient.java:185)
at
org.swift.jira.cli.JiraClient.getAuthenticationHelper(JiraClient.java:107)
at
org.swift.common.cli.helpers.DefaultRequestHelper.setConnectionProperties(DefaultRequestHelper.java:1043)
at
org.swift.common.cli.helpers.DefaultRequestHelper.setConnectionProperties(DefaultRequestHelper.java:1030)
at
org.swift.common.cli.helpers.DefaultRequestHelper.makeRequestWithUrlConnection(DefaultRequestHelper.java:724)
at
org.swift.common.cli.helpers.DefaultRequestHelper.makeUrlRequest(DefaultRequestHelper.java:690)
at
org.swift.common.cli.helpers.DefaultRequestHelper.makeRequest(DefaultRequestHelper.java:660)
at
org.swift.common.cli.helpers.DefaultRequestHelper.makeStandardRequest(DefaultRequestHelper.java:648)
at
org.swift.common.cli.helpers.AppfireRequestHelper.getServerInfo(AppfireRequestHelper.java:118)
at
org.swift.jira.cli.JiraClient.getRemoteServerInfo(JiraClient.java:2493)
at org.swift.jira.cli.JiraClient.getServerInfo(JiraClient.java:2455)
at org.swift.jira.cli.JiraClient.handleRequest(JiraClient.java:840) at
org.swift.common.cli.DefaultRemoteClient.process(DefaultRemoteClient.java:729)
at org.swift.common.cli.CliClient.doWork(CliClient.java:674) at
org.swift.common.cli.CliClient.doWork(CliClient.java:631) at
org.swift.jira.cli.JiraClient.main(JiraClient.java:166)
I managed to get this working by creating an API token and using that as the password. You can create an API token by visiting the https://id.atlassian.com/ site and selecting the API tokens on the left pane.
I hope this helps.

Google OAuth1 to OAuth2 migration - displays consent screen again

I followed OAuth1 to OAuth2 migration documentation and was able to get new refresh_token and access_tokens.
The issue is, Google displays approval screen again and list all the scopes. The whole point of migrating the credentials is that user should not see the approval screen.
Here is my POST request for migration:
POST https://accounts.google.com/o/oauth2/token HTTP/1.1
Authorization: OAuth realm="",oauth_consumer_key=[CONSUMER
KEY]",oauth_nonce="2c06a5da90ec4a62b737bdfb3922d675",oauth_signature_method="HMAC-SHA1",oauth_timestamp="1411677478",oauth_token="[OAUTH
TOKEN]",oauth_signature="oL%2b2JdOBCKcND8cSHSmHQMRN5NI%3d"
Content-Type: application/x-www-form-urlencoded Host:
accounts.google.com Content-Length: 194 Expect: 100-continue
Connection: Keep-Alive
grant_type=urn%3aietf%3aparams%3aoauth%3agrant-type%3amigration%3aoauth1&client_id=&client_secret=[GENERATED
SIGNATURE]
Further more, if I check https://security.google.com/settings/security/permissions?pli=1 page to see which application I have given access to, I see my new application there, with all the scopes that older application had.
I also made sure that I don't include approval_prompt=force
Any thoughts? Am I wrong in assuming that the user will not see the approval screen after migration?
You're right, the point of migrating the credentials is that the user should not see the approval screen. But if you added any new scopes, maybe to use some APIs, most of them require the user to grant permission and therefore a approval screen will be displayed again.
Can you clarify the steps and when does a user see the approval page? What scopes do your OAuth2 tokens have after the migration?
The migration is for a OAuth1 token that you have stored on your backend. With migration step you convert these to OAuth2 refresh token. You can start using these to make calls to Google APIs without a user showing up on your site.
Depending on how you got these OAuth1 tokens, you need to change that mechanism to start getting OAuth2 tokens. In general you want to do this only for the users you don't have a refresh token already stored as there is no point getting a new refresh token (if you do, they may see an approval screen).

Rails 3.1 OmniAuth with Facebook - Failure, but dont send error

I'm facing a weird problem.
I followed this tutorial : https://github.com/plataformatec/devise/wiki/OmniAuth:-Overview
It works perfectly with the exact same code on my local machine (with modification on APP_ID and SECRET).
But when I test it on another server, I cant get logged in with Facebook informations...
I click on the link (<%= link_to 'register with fb', user_omniauth_authorize_path(:facebook) %>) then I'm redirected well to Facebook which asks me if I allow the app and finally I get redirected to my site.
But I'm redirected to /user/sign_in ! And no record with the user retrieved from Facebook is created.
The log gives me :
Started GET "/users/auth/facebook" for 192.168.1.254 at 2011-07-25 19:06:11 +0400
Started GET "/users/auth/facebook/callback?code=grV09GQr[...]BbcM-mxklOu5E"
for 192.168.1.254 at 2011-07-25 19:06:12 +0400 Processing by
Users::OmniauthCallbacksController#failure as HTML Parameters:
{"code"=>"grV09GQrqjDepasyQpVhqSg0FINlr4h9[...]sSUooMrBRxBbcM-mxklOu5E"}
Redirected to http://mysite.com/users/sign_in Completed 302 Found in
1ms
Someone has an idea ?
Many Thanks
You are getting the sign-in page because this is the default behavior for the omniauth gem when an error occurs from facebook. You are getting rejected from facebook. If you were to decode the code in the returned URL, you might be able to figure out the reason. It would be helpful if the error handler did that.
With facebook connect you must put the url of your website in the facebook configuration. It is the canvas URL or web site url/domain in the configuration. If you don't have this set correctly, then facebook will reject your return request.