Is a redirect code returned to the client with a URI that the client needs to be redirected to? Once the user completes additional verification on the Balanced website, how are the results transmitted back to the server? Is it a configurable redirect uri?
Balanced will return you a 300 status code when it fails to identify a merchant. You can resubmit the request with additional information or you can redirect the merchant to the location supplied in the response and Balanced will attempt to gather more information and verify them.
When you redirect the user you must include a redirect_uri paramater which the merchant will be returned to at the end of the identification process.
You can also pass through information in the querystring so that the form is pre-filled for the user. These fields should be the same as you included in the original JSON payload, for a nested dictionary you enclose the field in square brackets. E.g.
{
"name": "Joel Spolskey",
"bank_account": {
"bank_code": 321174851
}
}
Should become
?name=Joel%20Spolskey&bank_account[bank_code]=321174851
Once Balanced has verified the Merchant, the user is redirected back to redirect_uri, along with the Merchant's email address and a new parameter called merchant_uri as an identifier. You would then POST the email_address and merchant_uri parameters to the account endpoint and it will create the account for you. If the user cancels out of the verification process they are redirected to the redirect_uri but doing a POST on the account endpoint will return the original 300 redirect since they do not have any identifying information in the system.
Related
Is there a way to forward query parameters from original request to auth-url? I know we have X-Original-URL but can we directly get them as query parameter for auth-url?
Ingress controller cuts off url query parameters from the original request when calling external authorization endpoint.
This is an issue in OAuth scenario when the OAuth server sends the authorization code back to the resource server.
The auth enpoint needs that code to get access token.
Try to use the image quay.io/aledbf/nginx-ingress-controller:0.185 it uses the rd parameter for the correct redirect url after the login.
You can also add State Parameter. It will help for oauth2_proxy.
State parameter will reserve the state prior to authentication request and pass random generated state value in request to authenticate and in call back request they will add state back i.e. Oauth2_Proxy generated id. Then Oauth2_Proxy will read that ID and provide the URL back and respond.
Take a look: ingress-nginx-issue, configuring-http-basic-authentication/, url-to-oauth-proxy-as-redirect.
If I were designing an API or protocol that uses HTTP URLs and wanted to use the userinfo subcomponent to designate something other than the requester's user name, would that be in violation of the spec?
E.g. user agent authenticated as user 'a#example.com' makes a request to http://b#example.com/stuff to access data controlled or pertaining to user 'b'.
RFC 3986 3.2.1 just says 'a user name' and not the client's user name:
The userinfo subcomponent may consist of a user name and, optionally, scheme-specific information about how to gain authorization to access the resource.
But RFC 7230 2.7.1 says
A sender MUST NOT generate the userinfo subcomponent (and its "#" delimiter) when an "http" URI reference is generated within a message as a request target or header field value. Before making use of an "http" URI reference received from an untrusted source, a recipient SHOULD parse for userinfo and treat its presence as an error;
Based on the above, it seems you can use the username component to mean what is wanted, but the server just can't respond with links/resource identifiers including a username.
After testing a link (E.g. link) in Firefox, it will display a warning and then make the HTTP request without the username if you choose to continue.)
i am trying to generate access token to collect linkedin data. I followed the instructions provided in the linkedin API documentaion. I created an app in developers page and got the following:
Application Details
• Company:
Fresher
• Application Name:
xxxxxxxxxx
• API Key:
75pcum6zb2cael
• Secret Key:
xxxxxxxxxxxxxxxx
• OAuth User Token:
xxxx-xxxx-xxxx-xxxx-xxxxxxxxxx
• OAuth User Secret:
xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx
Using the API Key i generated the authorization_code with the URL:
https://www.linkedin.com/uas/oauth2/authorization?response_type=code&client_id=75pcum6zb2cael&state=DCEEFWF45453sdffef424&redirect_uri=https://www.google.com
but when i finally tried to generate the access token using the below URL, i got an error response :
https://www.linkedin.com/uas/oauth2/accessToken?grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=https://www.google.com&client_id=75pcum6zb2cael&client_secret=xxxxxxxxxxxxxxxx
{"error_description":"missing required parameters, includes an invalid
parameter value, parameter more than once. : Unable to retrieve access
token : appId or redirect uri does not match authorization code or
authorization code expired","error":"invalid_request"}
Even after multilple validations, the same error messages appears.
please help. thanks.
finally, i got the access token. The authorization code expires in 20 seconds, so the access token URL must be called immediately after generating the authorization code.
Well, I went through the same problem and here is the process which i went through to fix it.
STEP#1: Authentication:
Firstly, the authentication API is to be hit to fetch the authentication token.
For this, a URL with Encoded parameters is to be hit as a GET request.
Example: https://www.linkedin.com/oauth/v2/authorization?response_type=code&client_id=[your_client_id]&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Flinkedin%2Fcallback&scope=r_emailaddress
Please note that here, the parameters are to be encoded programatically.
My non-encoded callback URL is: http://localhost:8080/linkedin/callback
Therefore, my encoded URL is: http%3A%2F%2Flocalhost%3A8080%2Flinkedin%2Fcallback
Once you hit this as a GET request, you will receive a callback with a code and an optional state parameter.
STEP#2: Getting Access Token:
There are three pre-requisites to this call:
The call must be POST
It must have a header Content-Type with value application/x-www-form-urlencoded
The data must be sent in request body.
The value of redirect_url MUST BE SAME as in the previous call.
In my case, it was: http://localhost:8080/linkedin/callback
Now the trick here is, that the call in (STEP#1 Authentication) was a GET request. Therefore, the redirect_url had to be programatically encoded.
Since the second call for is POST and is also application/x-www-form-urlencoded encoded, therefore the request body parameters do not have to be explicitly encoded. So, in this case, the redirect_uri would be sent as-is (http://localhost:8080/linkedin/callback)
Here is a snapshot of my Access Token API via postman:
My problem was in redirect_uri which contained url with query parameters (like redirect_uri=encodeURIComponent(http://example.com/callback?query=string)).
If redirect url is completely different linkedin will show you an error before showing you login form, but if redirect_url matches what you specified in linkedin app and contains extra query parameters, you'll not get an error, so once login form is submitted you'll get an invalid code and as a result error as above.
This error may be scopes related.
On the details of your application when selecting scopes there is this message:
Selecting both r_basicprofile and r_fullprofile is redundant.
r_basicprofile will be selected if neither r_basicprofile nor
r_fullprofile is checked.
If you are selecting both r_basicprofile and r_fullprofile just uncheck r_basicprofile or remove it from your Authorization Code Request.
I had the same problem, in my case I was using different redirect_uri for authorization and for access token. I had "proxy": "localhost:3001" in my package.json, and it overriden my request_uri.
So my suggestion: make sure the hosts and redirect_uri are all the same for two requests (both backend and server side).
I am trying to login to a site, and then view user details.
The API documentation from the site is:
LogOn : All Calls with JSON and return JSON type
post - https://www.bit2c.co.il/Account/LogOn {UserName:'',Password:'',SecondFactor:[optional]}
return true if OK , error list of strings if not
Balance - GET https://www.bit2c.co.il/Account/Balance
return UserBalance as JSON
I've tried connecting to the site using
import requests
session=requests.session()
session.auth = ("username", "pass")
session.post("https//www.bit2c.co.il/Account/Balance")
but i am getting response 200 and the response content is "you must login".
What am I doing wrong ?
What kind of session? What is on server-side? Can you post the raw request/response pair(s)?
If PHP or ASP runs on server-side, you must capture the Set-Cookie header of the response to the login request, find the session cookie and in consequent requests you must set the Cookie header with the session cookie name and value captured previously.
This is a conceptual question.
I have a client (mobile) application which needs to support a login action against a RESTful web service. Because the web service is RESTful, this amounts to the client accepting a username/password from the user, verifying that username/password with the service, and then just remembering to send that username/password with all subsequent requests.
All other responses in this web service are provided in a JSON format.
The question is, when I query the web service simply to find out whether a given username/password are valid, should the web service always respond with JSON data telling me its successful or unsuccessful, or should it return HTTP 200 on good credentials and HTTP 401 on bad credentials.
The reason I ask is that some other RESTful services use 401 for bad credentials even when you're just asking if the credentials are valid. However, my understanding of 401 responses are that they represent a resource that you are not supposed to have access to without valid credentials. But the login resource SHOULD be accessible to anyone because the entire purpose of the login resource is to tell you if your credentials are valid.
Put another way, it seems to me that a request like:
myservice.com/this/is/a/user/action
should return 401 if bad credentials are provided. But a request like:
myservice.com/are/these/credentials/valid
should never return 401 because that particular URL (request) is authorized with or without valid credentials.
I'd like to hear some justified opinions one way or the other on this. What is the standard way of handling this, and is the standard way of handling this logically appropriate?
First off. 401 is the proper response code to send when a failed login has happened.
401 Unauthorized
Similar to 403 Forbidden, but specifically for use when authentication is required and has failed or has not yet been provided. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource.
Your confusion about, myservice.com/are/these/credentials/valid sending back 401 when you just do a check, I think is based on the fact that doing boolean requests in REST often is wrong by the RESTful constraints. Every request should return a resource. Doing boolean questions in a RESTful service is a slippery sloop down to RPC.
Now I don't know how the services that you looked on are behaving. But a good way of solving this is to have something like an Account object, that you try to GET. If your credentials are correct, you will get the Account object, if you don't want to waste bandwidth just to do a "check" you can do a HEAD on the same resource.
An Account Object is also a nice place to store all those pesky boolean values that otherwise would be tricky to create individual resources for.
401 should be sent only when the request needs authorization header field and authorization fails. Since the Login API doesn't require authorization, hence 401 is the wrong error code in my opinion
As per the standard here https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
*10.4.2 401 Unauthorized
The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" [43].*
If the 401 response code is misleading for user authentication, the API can send HTTP status code 200 OK for both successful and failed authentication, but set a custom header on the authentication successful response and omit that header on failed logins.
The client can check if the header exists or not and decide the action.
Example: SpringBoot API Response
The call to OK when login is successful sets the header "gotyouin" with a value (anything). Call to failed does not add the header and client can treat this as a failed login attempt.
public class LoginResponseEntityHelper {
public static ResponseEntity<?> ok(String token) {
return ResponseEntity.status(HttpStatus.OK).header("gotyouin", token).body(null);
}
public static ResponseEntity<?> failed() {
return ResponseEntity.status(HttpStatus.OK).body(null);
}}
It is logical to use 401 http status code when access to a resource is denied because the request lacks or has incorrect credentials. And when correct credentials are provided, the request should complete successfully granting access to the protected resource.
Applicable for your case: myservice.com/this/is/a/user/action.
Maybe we should be clear about this credentials
In most secure applications, credentials are needed to access protected resource(s). These credentials can be sent along every request via HTTP header. Specifically the Authorization Header.
Therefore the Authorization header contains credentials to allow a user to access protected resource(s).
Remember that a user who was verified successfully as an authorized user(successful login), is the one given this priviledged credentials to allow for access on protected resources on the server.
From the server point of view, a HTTP request targeting a protected resource yet it is lacking credentials or containing invalid credentials may cause to validly send back 401 response code.
Therefore the Login API should not send a 401 response code because of a failed login attempt. It is misleading. Reasoning out that you are requesting to the server application via the Login API to grant you with credentials required to access resources that are protected. By itself, the Login API is not a protected resource.
So what is the correct response status?
Well I will opine towards sending back a 400 response code because a failed login attempt is a client error who is at fault for not providing the correct username or password.
According to RFC standards about 400 code:
The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing)
Again I will reiterate that failed login is a client error due to providing details that are incorrect. Sending back a 400 doesn't have to mean that the request syntax is malformed. But a malformed syntax is one of the reasons.
Sending a 401 would really be misleading as the user doesn't need to provide authentication information to access the login API.