Aqueduct authentication requests {"error":"invalid_client"} - dart

I try to set up authentication via oauth 2.0 in my aqueduct app. I have followed step by step tutorial at aqueduct.io addjusting it to my app.
Unfortunately I have stuck after creating client at first authentication requests:
POST http://localhost:8888/auth/token -H 'Authorization: Basic dGVzdG5hbWU6dGVzdHBhc3N3b3Jk' -H 'Content-Type: application/x-www-form-urlencoded' -d 'username=testname&password=testpassword&grant_type=password'
If entryPoint looks like:
#override
Controller get entryPoint {
final router = Router();
router
.route('/auth/token')
.link(() => Authorizer.basic(authServer));
//.link(() => AuthController(authServer));
router
.route('/register')
.link(() => RegisterController(context, authServer));
return router;
Then I have got error:
curl: (6) Could not resolve host: Basic
curl: (6) Could not resolve host: dGVzdG5hbWU6dGVzdHBhc3N3b3Jk'
curl: (6) Could not resolve host: application
'password' is not recognized as an internal or external command,
operable program or batch file.
'grant_type' is not recognized as an internal or external command,
operable program or batch file.
And if I change Authorizer.basic to AuthController (according to tutorial):
router
.route('/auth/token')
//.link(() => Authorizer.basic(authServer));
.link(() => AuthController(authServer));
then the same error starts with extra line:
{"error":"invalid_client"}

Related

Rails 'unsafe redirect' from strange curl request

I am getting occasional errors of this type in production and staging:
Unsafe redirect to "https://${ip}:${port}/businesses/new", pass allow_other_host: true to redirect anyway.
It is being caused by Curl requests from a random IP:
User-Agent: "curl/7.64.1"
Accept: "*/*"
Host: "${ip}:${port}"
Version: "HTTP/1.1"
I do not get it with any other URLs processed within the app.
When I try the same curl request in development I get this (which is correct):
Rails - [ActionDispatch::HostAuthorization::DefaultResponseApp] Blocked host: "${ip}:${port}"
I cannot find where the difference is that makes this throw an exception in production.
Any insights on this issue would be appreciated.

Hyperledger Sawtooth - Preflight error while submitting transaction

I am trying to submit a transaction to Hyperledger Sawtooth v1.0.1 using javascript to a validator running on localhost. The code for the post request is as below:
request.post({
url: constants.API_URL + '/batches',
body: batchListBytes,
headers: { 'Content-Type': 'application/octet-stream' }
}, (err, response) => {
if (err) {
console.log(err);
return cb(err)
}
console.log(response.body);
return cb(null, response.body);
});
The transaction gets processed when submitted from an backend nodejs application, but it returns an OPTIONS http://localhost:8080/batches 405 (Method Not Allowed) error when submitted from client. These are the options that I have tried:
Inject Access-Control-Allow-* headers into the response using an extension: The response still gives the same error
Remove the custom header to bypass preflight request: This makes the validator throw an error as shown:
...
sawtooth-rest-api-default | KeyError: "Key not found: 'Content-Type'"
sawtooth-rest-api-default | [2018-03-15 08:07:37.670 ERROR web_protocol] Error handling request
sawtooth-rest-api-default | Traceback (most recent call last):
...
The unmodified POST request from the browser gets the following response headers from the validator:
HTTP/1.1 405 Method Not Allowed
Content-Type: text/plain; charset=utf-8
Allow: GET,HEAD,POST
Content-Length: 23
Date: Thu, 15 Mar 2018 08:42:01 GMT
Server: Python/3.5 aiohttp/2.3.2
So, I guess OPTIONS method is not handled in the validator. A GET request for the state goes through fine when the CORS headers are added. This issue was also not faced in Sawtooth v0.8.
I am using docker to start the validator, and the commands to start it are a slightly modified version of those given in the LinuxFoundationX: LFS171x course. The relevant commands are below:
bash -c \"\
sawadm keygen && \
sawtooth keygen my_key && \
sawset genesis -k /root/.sawtooth/keys/my_key.priv && \
sawadm genesis config-genesis.batch && \
sawtooth-validator -vv \
--endpoint tcp://validator:8800 \
--bind component:tcp://eth0:4004 \
--bind network:tcp://eth0:8800
Can someone please guide me as to how to solve this problem?
CORS issues are always the best.
What is CORS?
Your browser trying to protect users from bring directed to a page they think is the frontend for an API, but is actually fraudulent. Anytime a web page tries to access an API on a different domain, that API will need to explicitly give the webpage permission, or the browser will block the request. This is why you can query the API from Node.js (no browser), and can put the REST API address directly into your address bar (same domain). However, trying to go from localhost:3000 to localhost:8008 or from file://path/to/your/index.html to localhost:8008 is going to get blocked.
Why doesn't the Sawtooth REST API handle OPTIONS requests?
The Sawtooth REST API does not know the domain you are going to run your web page from, so it can't whitelist it explicitly. It is possible to whitelist all domains, but this obviously destroys any protection CORS might give you. Rather than try to weigh the costs and benefits of this approach for all Sawtooth users everywhere, the decision was made to make the REST API as lightweight and security agnostic as possible. Any developer using it would be expected to put it behind a proxy server, and they can make whatever security decisions they need on that proxy layer.
So how do you fix it?
You need to setup a proxy server that will put the REST API and your web page on the same domain. There is no quick configuration option for this. You will have to set up an actual server. Obviously there are lots of ways to do this. If you are already familiar with Node, you could serve the page from Node.js, and then have the Node server proxy the API calls. If you are already running all of the Sawtooth components with docker-compose though, it might be easier to use Docker and Apache.
Setting up an Apache Proxy with Docker
Create your Dockerfile
In the same directory as your web app create a text file called "Dockerfile" (no extension). Then make it look like this:
FROM httpd:2.4
RUN echo "\
LoadModule proxy_module modules/mod_proxy.so\n\
LoadModule proxy_http_module modules/mod_proxy_http.so\n\
ProxyPass /api http://rest-api:8008\n\
ProxyPassReverse /api http://rest-api:8008\n\
RequestHeader set X-Forwarded-Path \"/api\"\n\
" >>/usr/local/apache2/conf/httpd.conf
This is going to do a couple of things. First it will pull down the httpd module from DockerHub, which is just a simple static server. Then we are using a bit of bash to add five lines to Apache's configuration file. These five lines import the proxy modules, tell Apache that we want to proxy http://rest-api:8008 to the /api route, and set the X-Forwarded-Path header so the REST API can properly build response URLs. Make sure that rest-api matches the actual name of the Sawtooth REST API service in your docker compose file.
Modify your docker compose file
Now, to the docker compose YAML file you are running Sawtooth through, you want to add a new property under the services key:
services:
my-web-page:
build: ./path/to/web/dir/
image: my-web-page
container_name: my-web-page
volumes:
- ./path/to/web/dir/public/:/usr/local/apache2/htdocs/
expose:
- 80
ports:
- '8000:80'
depends_on:
- rest-api
This will build your Dockerfile located at ./path/to/web/dir/Dockerfile (relative to the docker compose file), and run it with its default command, which is to start up Apache. Apache will serve whatever files are located in /usr/local/apache2/htdocs/, so we'll use volumes to link the path to your web files on your host machine (i.e. ./path/to/web/dir/public/), to that directory in the container. This is basically an alias, so if you update your web app later, you don't need to restart this docker container to see the changes. Finally, ports will take the server, which is at port 80 inside the container, and forward it out to localhost:8000.
Running it all
Now you should be able to run:
docker-compose -f path/to/your/compose-file.yaml up
And it will start up your Apache server along with the Sawtooth REST API and validator and any other services you defined. If you go to http://localhost:8000, you should see your web page, and if you go to http://localhost:8000/api/blocks, you should see a JSON representation of the blocks on chain. More importantly you should be able to make the request from your web app:
request.post({
url: 'api/batches',
body: batchListBytes,
headers: { 'Content-Type': 'application/octet-stream' }
}, (err, response) => console.log(response) );
Whew. Sorry for the long response, but I'm not sure if it is possible to solve CORS any faster. Hopefully this helps.
The transaction Header should have details like, address of the block where it would be save. Here is example which I have used and is working fine for me :
String payload = "create,0001,BLockchain CPU,Black,5000";
logger.info("Sending payload as - "+ payload);
String payloadBytes = Utils.hash512(payload.getBytes()); // --fix for invaluid payload seriqalization
ByteString payloadByteString = ByteString.copyFrom(payload.getBytes());
String address = getAddress(IDEM, ITEM_ID); // get unique address for input and output
logger.info("Sending address as - "+ address);
TransactionHeader txnHeader = TransactionHeader.newBuilder().clearBatcherPublicKey()
.setBatcherPublicKey(publicKeyHex)
.setFamilyName(IDEM) // Idem Family
.setFamilyVersion(VER)
.addInputs(address)
.setNonce("1")
.addOutputs(address)
.setPayloadSha512(payloadBytes)
.setSignerPublicKey(publicKeyHex)
.build();
ByteString txnHeaderBytes = txnHeader.toByteString();
byte[] txnHeaderSignature = privateKey.signMessage(txnHeaderBytes.toString()).getBytes();
String value = Signing.sign(privateKey, txnHeader.toByteArray());
Transaction txn = Transaction.newBuilder().setHeader(txnHeaderBytes).setPayload(payloadByteString)
.setHeaderSignature(value).build();
BatchHeader batchHeader = BatchHeader.newBuilder().clearSignerPublicKey().setSignerPublicKey(publicKeyHex)
.addTransactionIds(txn.getHeaderSignature()).build();
ByteString batchHeaderBytes = batchHeader.toByteString();
byte[] batchHeaderSignature = privateKey.signMessage(batchHeaderBytes.toString()).getBytes();
String value_batch = Signing.sign(privateKey, batchHeader.toByteArray());
Batch batch = Batch.newBuilder()
.setHeader(batchHeaderBytes)
.setHeaderSignature(value_batch)
.setTrace(true)
.addTransactions(txn)
.build();
BatchList batchList = BatchList.newBuilder()
.addBatches(batch)
.build();
ByteString batchBytes = batchList.toByteString();
String serverResponse = Unirest.post("http://localhost:8008/batches")
.header("Content-Type", "application/octet-stream")
.body(batchBytes.toByteArray())
.asString()
.getBody();

Passing remote_user to lua file

I am following the next tuto section LDAP Authentication. The configuration nginx file and the lua script are here and here. After the commands
sbin/nginx -p $PWD -c conf/nginx-ldap-auth.conf
python backend-sample-app.py
python nginx-ldap-auth-daemon.py
According the log of nginx-ldap-auth-daemon.py I have success with login, i.e. 200 OK auth user admin. But I get a 500 Internal Server Error. In the lua.log I get
/usr/local/openresty/nginx/authorize_es_ldap.lua: in function </usr/local/openresty/nginx/authorize_es_ldap.lua:1> while sending to client, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", host: "localhost:8881", referrer: "http://localhost:8881/"
2016/09/29 23:35:27 [error] 23987#0: *10 lua entry thread aborted: runtime error: /usr/local/openresty/nginx/authorize_es_ldap.lua:50: attempt to concatenate global 'role' (a nil value)
I think that the problem is because in the tutorial there is a gap, that is how to pass the remote_user variable to lua script. I am trying to add self.send_header('LDAPUser',ctx['user']) around the line 204, before to end_headers and after to seld.send_response(200).
Could you help me please?

WebSphere Docker OAuth

I need to implement OAuth against an IBM WebSphere server. For that purpose I built a docker environment https://github.com/hhoechtl/websphere-oauth according to http://www.ibm.com/developerworks/websphere/techjournal/1305_odonnell2/1305_odonnell2.html
But if I try to get a token
curl -X POST -H "Accept-Charset: UTF-8" -H "Content-Type: application/x-www-form-urlencoded" -d 'grant_type=password&client_id=LibertyRocks&client_secret=AndMakesConfigurationEasy&username=admin&password=admin' "https://192.168.99.100:9443/oauth2/endpoint/DemoProvider/token"
I get the error
{
"error_description": "CWWKS1406E: The token request had an invalid client credential. The request URI was /oauth2/endpoint/DemoProvider/token.",
"error": "invalid_client"
}
But according to my server.xml that should be correct. What am I missing?
Would you be able to turn on and provide the server trace for that invocation? The message indicates that either credentials weren't found in the request, or credentials were found but were invalid for that client. It would be useful to know which is the case here.
You can enable trace by adding this snippet to your server.xml:
<logging traceSpecification="*=info=enabled:com.ibm.ws.security.*=all=enabled:com.ibm.oauth.*=all=enabled" />
The next day it just worked, no idea why.

rails api: send curl in controller test

I'm building a Rails API, and I'm writing a test that sending a curl request works. This seems to be a testing issue, because an actual curl request works:
$ curl -X POST -d temperature=68 localhost:3000/temperature_readings.json
# => {"status":200}
Here's the controller method:
def create
TemperatureReading.create(temperature: params[:temperature])
render json: { status: 200 }
end
Here's the test:
context 'works via a curl request' do
it 'works' do
system "curl -X POST -d 'temperature=68' #{temperature_readings_url(format: 'json')}"
expect(TemperatureReading.last.temperature).to eq(68)
end
end
I'm getting an error from curl that test.host does not resolve:
curl: (6) Could not resolve host: test.host
That makes sense, because when I call temperature_readings_url(format: 'json') from within pry in that method, I get http://test.host/temperatures.json.
Is there a better way to test that my controller can successfully handle a curl request and create the correct record with the correct attributes?
What I've Tried
I made sure that protect_from_forgery with: :null_session is set in ApplicationController so that it doesn't fail with an exception when it can't find the token
I tried adding -H 'Content-Type:application/json' to the curl request to make sure it's hitting the json format in the controller. But it really seems to boil down to the fact that the working URL in the testing environment is test.host.
So I explicitly set request.host to localhost:3000 in the test, which felt a little hacky. But then of course it just posted to my dev database and not my test database, so the test still failed.
Your app doesn't know its host outside the request context, so you have to provide it anyway. This is also hacky:
temperature_readings_url(format: 'json', host: 'localhost:3000').
But you can define it globally in config/enviroments/test.rb:
Rails.application.routes.default_url_options[:host] = 'localhost:3000'
so in test enviroment all url helpers will return localhost:3000 as host by default.

Resources