I am using the Java Toolkit for Rally REST API, and I am concerned about security of credentials being passed using the RallyRestApi class. Does RallyRestApi use an HTTP GET or POST method for authenticating?
Here is the usage example from the Java Toolkit for Rally REST API page:
RallyRestApi restApi = new RallyRestApi(new URI("https://rally1.rallydev.com"), "user#company.com", "password");
Thanks,
Nick.
The toolkit uses basic auth, which basically sends the username/password in an encoded header. As long as you are connecting to the server via SSL (https protocol rather than http) your credentials will not be passed in clear text.
Related
It might sound like a repeated question at first, but I've gone through all the blogs/ tutorials/ videos I found but none of them actually says how you run that request. Example: for a RESTful request, you code in NodeJs, hit the route(https://localhost/3000/api/getStudent) and get the response. In code you use router.post('/getStudent', async (req,res) => {
// Check response here or manipulate
})
But in soap after coding all the functions like in here-
https://medium.com/metrosystemsro/with-node-js-wrap-backend-soap-webservices-in-a-restful-api-a96887575046
https://dafabulousteach.wpcomstaging.com/2016/05/19/making-a-soap-call-with-node/
https://betterprogramming.pub/how-to-perform-soap-requests-with-node-js-4a9627070eb6
Where do I call the the function and how do I pass parameters and test it? And how do I check the response?
To place this in the context of what you are asking about, a SOAP service is just a server listening on an address for POST requests that have an XML payload. That's it.
So if your SOAP web service address is http://example.com/service_endpoint then you can call the web service by making a POST HTTP request at this address and sending it a SOAP XML message as payload.
Obviously, the XML message in the request must match something that the service expects and you know how to build that XML either by reading documentation or by using the WSDL of the SOAP web service.
So if you know how to make a POST HTTP request to a REST service address and send it a XML payload (although most commonly for REST you use JSON), you already know how to call a SOAP web service.
Now, for convenience, because SOAP is a protocol, the way you call the service and what it expects as XML payload is described by the WSDL, and you can use tools that read the WSDL and create a client API that you can invoke like any other method in your code. The tools handle the details of the HTTP POST request for you, and also the marshalling of any parameters to XML. This is probably what you found confusing.
So let's take an example.
If you have, say, a service that has an operation named savePerson which accepts firstName and lastName as parameters and is described in the WSDL, then your tooling might generate a client that has such a method and accepts a Person object and you can call it like:
var response = client.savePerson({ "firstName": "Kim", "lastName": "Seokjin" });
or some variation of this. You then get a response that you can read just like any other object. You might get a promise instead, or an event, or whatever way the client chooses for how to work. When you use this code, what happens is that the client performs a HTTP POST request behind the scenes for you and marshals the person object to XML, something like this:
POST /service_endpoint
Host: http://example.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<savePerson>
<person>
<firstName>Kim</firstName>
<lastName>Seokjin</lastName>
</person>
</savePerson>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
You can obviously send this request yourself with whatever HTTP library you prefer if you don't want to generate a client from the WSDL. But people prefer to use a generated client instead of dealing with these details directly (i.e. making HTTP requests, parsing XML, etc).
I am trying to get new access tokens before they expire using reconnect api endpoint, but the api call to https://appcenter.intuit.com/api/v1/Connection/Reconnect is being redirected to https://quickbooks.intuit.com/learn-support/en-us/do-more-with-quickbooks/third-party-app-security-requirements-updating-soon/01/428295, rather the expected response. Am i missing something here? Appreciate the help.
According to Intuit's documentation, you're using the wrong URL:
https://developer.intuit.com/app/developer/qbo/docs/develop/authentication-and-authorization/oauth-2.0#refresh-the-token
Did you try using the correct URL?
From the docs:
To refresh an access token, your application sends an HTTPS POST request to
Intuit’s authorization server
(https://oauth.platform.intuit.com/oauth2/v1/tokens/bearer)
that includes the following parameters:
const ClientOAuth2 = require('client-oauth2');
const oauth2 = new ClientOAuth2({
clientId: 'clientId',
clientSecret: 'clientSecret',
accessTokenUri: 'https://fakeurl.com/v1/auth/token',
});
oauth2 .credentials.getToken().then(function (user) {
console.log(user);
}).catch(function (error) {
console.log(error);
});
Is there a way i can include proxy settings when requesting for a token given i am running this code inside a corporate network
I had a quick look and couldn't find an easy way to do it. Other than proxy features I noticed also that it is missing Open Id Connect features such as these:
Looking up metadata
Authorization Code Flow (PKCE)
Calls to the User Info Endpoint
REQUIREMENTS
Choosing a library for your apps is an important decision, and here are a few common things people usually look for:
Standards Based (works for any Authorization Server)
Certified as following the latest OAuth 2.1 and Open Id Connect recommendations
Supports HTTP proxying (highly useful to view OAuth messages when developing)
NODEJS SOLUTION
If you are using Node it might be worth considering the node openid-client library, which is the one I use. Here is some relevant code from an API of mine:
Looking up metadata - note that an agent can be supplied to support proxying
Setting the HTTP proxy - I use TunnelAgent.httpsOverHttp to proxy calls to HTTPS OAuth URLs
OAuth Operations - note that there are some custom classes that make these tasks easier
I'm trying to interact with an API via Python3's Requests module but the authentication is not working . I am able to take the exact same url with the same username/password and use the API via my Firefox browser.
There are a few complications with the setup, so let me explain.
The device I'm trying to talk with uses https but I don't have access to the certs so I'm choosing not to verify. I'm able to interact with Requests with older models that only use http no problem.
The device is on a local network but my company's network utilizes proxies that interfere with communication to devices on a local network so I turn these off.
Here's an example of my code:
session = requests.Session()
auth = ('username', 'password')
session.auth = auth
s.trust_env = False # remove proxies (see 2 above)
response = session.get(
url='https://mylocalurl/api/',
params={'apikey' : 'myapikey',
'req' : 'generalInfo'},
verify=False # don't verify SSL cert (see 1 above)
)
My first thought was that I had to specify the encoding of the credentials sent since I'm able to use those in my browser. I've tried doing auth = (b'username', b'password') with no luck. I looked at the response.content and found b'<?xml version="1.0" encoding="iso-8859-1"?>\n in the first line so I tried specifying that by auth = ('username'.encode('iso-8859-1'), 'password'.encode('iso-8859-1')) but still no luck.
The questions I have are:
The API's server is LightTPD, is there something particular with authenticating with this server via Python that I'm missing?
Do I have to verify my SSL cert to authenticate? Wouldn't make sense but I'm asking anyway.
Is there any more information I could gleam from the 401 response that could help me determine how to send the credentials in a way the server will accept?
I'm working in an application which delivers push content to a group of web applications hosted in different domains. I'm using Sails.js and Socket.io, and structured it like this:
The client script, running on each web application's client's browser, is something like:
socket.on('customEvent', function(message){
//do something with message on event trigger
}
And then, in the server, the event 'customEvent' is emitted when needed, and it works (e.g. on the onConnect event: sails.io.emit('customEvent',{message ...}).
But I'm facing a problem when it comes to handle authorization. The first approach I've tried is a cookie-based auth, as explained here (by changing the api/config/sockets.js function authorizeAttemptedSocketConnection), but it isn't a proper solution for production and it isn't supported in browsers with a more restrictive cookie policy (due to their default prohibition to third-party cookies).
My question is: how to implement a proper cross-browser and cross-domain authorization mechanism using sails.js, that can be supported in socket.io's authorization process?
======
More details:
I also tried adding a login with a well-known oauth provider (e.g. facebook), using this example as a base. I've got the Passport session, but I'm still unable to authenticate from the client script (it only works in pages hosted by my node app directly).
A JSONP request to obtain the session might be a solution, but it didn't work well in Safari. Plus I prefer the user to be authenticated in one of the web apps, rather than in my node application directly.
I believe your routes must handle CORS mate. Example:
'/auth/logout': {
controller: 'AuthController',
action: 'logout',
cors: '*'
},
Of course you can specify the list of ip your are accepting (and then replace the '*').
Worth mentionning that you must specify where socket.io has to connect to (front-end JS):
socket = io.connect(API.url);
For any common http GET/PUT/POST/DELETE, please ensure that your ajax envelope goes with the credentials (cookie). For example with angular:
$httpProvider.defaults.withCredentials = true
Let me know how it goes.