Certificate specified in header with openUI5 for SSL connection - ssl

I am trying to figure out how can I connect to Odata with ssl certificate authentification. We are using it with openUI5. Application is running as mobile application.
I tried several connection types on mobile device:
http is working good
https with optional certificate works good
https with required certificate Cannot access data
I also tried several connection types from browser:
http is working good
https with optional certificate works good
https with required certificate Can access data
So i was thinking that when I specify the certificate inside of header when creating the oModel inside of the app, it would work. But I don't know how to specify it correctly.
I tried to access certificates using this class:
https://help.sap.com/saphelp_smp235/helpdata/en/94/78b8de6c9110149d2cd7d1ca6ec99d/content.htm
It looks like this:
var certStore = listAvailableCertificatesFromFileSystem();
var certPaths = certStore.listAvailableCertificatesFromFileSystem("/sdcard/", "p12");
var cert = certStore.getSignedCertificateFromFile(certPaths[0], servicePassword);
var headersMap = [];
headersMap["SSL_CLIENT_CERT"] = cert.signedCertificate; // here I dont know how could I access it.
this.oModel = new sap.ui.model.odata.v2.ODataModel(this.serviceUrl, {
user: serviceLogin,
password: servicePassword,
withCredentials: true,
disableHeadRequestForToken: false,
useBatch: false,
headers: headersMap // here i specify the header...
});
Thank you

Related

Heroku Express / Nextjs client cookie not being set

So I'm having a bit of an issue where I have two apps hosted on Heroku the first being an Express application with the following cookie settings
const cookieSettings = {
maxAge: expiryTime,
...cookieOptions || {},
// For security these properties should always remain below the spread
httpOnly: true,
secure: process.env.NODE_ENV !== "development",
sameSite: "none",
path: "/",
}
And a Nextjs app which has some middleware that uses the cookie for login control to protect routes.
Locally I have no issues with the following login logic within the login route which sets the cookie browser side
const cookie = getCookie({ tokenOptions: { id: user._id } });
res.setHeader("Set-Cookie", cookie);
return res.sendStatus(200);
I have read there is issues with Heroku as it's on the public list of domains so the browser wont set if it comes from this but the issue I'm having is on a custom domain. My domain is https://www.mydomain.co.uk but for some reason I can't get it to set when I'm on this domain.
When using Postman I do get the cookie back but the domain comes from my API domain ie api.reviewcircle.co.uk which I think is why the browser isn't setting the cookie as the domains don't match but I can't find any info on how to fix this so would be great if anyone has any ideas.
You can see the cookie is included in the response but isn't set:

Ignore expired SSL Certificates in Meteor HTTP Calls

I got an old web app runing Meteor 1.6.1.1 in which we request data from restcountries.com. Unfortuanately Meteor now thinks that their certificate has expired. Presumable because of the R3 Certificate that expired a while ago. Since migration/update to another framework is not planned, I wanted to disable certificate verification for now. But I can't figure out how. I've tried setting strictSSL to false in the call options, but it doesn't have any effect:
var response = HTTP.get(apiUrl, {
headers: {
"User-Agent": "Meteor/1.0", //Required for EUROSTAT provider
"Accept": "application/json"
},
strictSSL: false
}).data;
You can use the env variable of Node: NODE_TLS_REJECT_UNAUTHORIZED
https://docs.meteor.com/expired-certificate.html

How to use SSL correctly in Meteor?

I am using peerjs-server with self-signed certificates as follow (in the server):
var base = process.env.PWD;
var fs = Npm.require('fs');
var PeerServer = require('peer').PeerServer;
var server = PeerServer({
port: 9000,
path: '/',
ssl: {
key: fs.readFileSync(base + '/certificates/key.pem', 'utf8'),
cert: fs.readFileSync(base + '/certificates/cert.pem', 'utf8')
}
});
And connecting to it as follow (in the client):
window.peer = new Peer({
host: 'localhost',
port: 9000,
path: '/',
debug:3,
config: {'iceServers': [
{ url: 'stun:stun.l.google.com:19302' },
{ url: 'stun:stun1.l.google.com:19302' },
]}
});
The above code (client) works when I don't use self-signed certificates.
The problem I am facing now is, how to link those self-signed certificates in the client when connecting to the server?
Non of the examples I found like this one are using Meteor and I am struggling to achieve the same with meteor.
I am not familiar with PeerJS and it seems like its not working fully anyhow.
I would rather use Galaxy, or a self hosted linux server like AWS, DigitalOcean and run meteor build to create a regular node app.
If you then set the environmnent variable of the URL to "https://myapp.com", and also add the force-ssl package.
This will get your Meteor app to always use a secure connection.

Using https on heroku

I'm trying to get my app on heroku to be 'https everywhere'. So far the app is like this:
"use strict";
console.log('working');
//Initial setup
var path, https, privateKey, certificate, port, cdjshelp, util, cookies, oauth, twitter, crypto, _, options, express, auth, lodash, dust, dustjs,
dustjsHelpers, commonDustjsHelpers, app, db, fs, mongoose, mongooseTimes, Comment, Bird, Sighting, Site, User,
Backbone, io;
//node modules, express and dust declarations
path = require('path');
util = require('util');
fs = require('fs');
https = require('https');
privateKey = fs.readFileSync('./config/privatekey.pem').toString();
certificate = fs.readFileSync('./config/certificate.pem').toString();
crypto = require('crypto');
//APP Defn...
app = require('./config/appSetup')(dustjs);
//******** SERVER CONFIG **********//
var port = process.env['PORT'] = process.env.PORT || 4000; // Used by https on localhost
options = {
key: privateKey,
cert: certificate
}
https.createServer(options, app).listen(port, function() {
console.log("Express server listening with https on port %d in %s mode", this.address().port, app.settings.env);
});
I've used the openSSL CLI to generate a privatekey.pem and a certificate.pem and loaded them as options.
I know that heroku has a procedure if you're using DNS records to have the app serve to your own domain. I know that you have to go through the procedure listed here. I'm not remapping any urls or altering any records - my url is birdsapp.heroku.com.
Heroku uses piggyback SSL, so if you setup an http server your app will respond to https requests without any additional config. The problem there is that the http routes are still available, so I've stuck to setting an https server only - but it's timing out with nothing in the logs, so I think that there's a problem with the SSL setup.
Is the above setup correct? Is that the best way to do basic https server on heroku?
OK, it's actually much simpler than that...
You simply create an http server:
//******** SERVER CONFIG **********//
var port = process.env['PORT'] = process.env.PORT || 4000;
http.createServer(app).listen(port, function() {
console.log("Express server listening with http on port %d in %s mode", this.address().port, app.settings.env);
});
and add a route redirect:
app.all('*', function(req, res, next) {
if (req.headers['x-forwarded-proto'] != 'https')
res.redirect('https://' + req.headers.host + req.url)
else
next() /* Continue to other routes if we're not redirecting */
});
heroku takes care of the rest, setting up an http server which is a mirror of your http server and uses their certs, etc.

WebRTC TURN Server - I set it up, but it's not working

I've set up a text chat service using the PeerJS implementation of WebRTC's data channel. PeerJS provides a basic signalling server for this purpose, but I have tried to replace that with STUN and TURN servers set up through XirSys (recommended by SimpleWebRTC, another WebRTC library). I haven't deployed to the web yet.
Using Node to serve my static files locally, it will work on a local network (when I am sitting next to the person and they navigate to my ip/port in the browser), but will not work when connecting through different access points on the same network (i.e. at work, on opposite ends of the building).
My hypothesis is that it's hitting a firewall, but still directing traffic to PeerJS' signalling server without falling back to the XirSys STUN and TURN servers I've tried to set up. Here's the code I'm working with:
var stun = {};
var turn1 = {};
var turn2 = {};
$.ajax({
type: "POST",
dataType: "json",
url: "https://api.xirsys.com/getIceServers",
data: {
ident: "myusername",
secret: "long-alphanumeric-secret-key",
domain: "www.adomain.com",
application: "anapp",
room: "aroom",
secure: 1
},
success: function (data, status) {
console.log(data);
stun = data.d.iceServers[0];
turn1 = data.d.iceServers[1];
turn2 = data.d.iceServers[2];
},
async: false
});
var conn;
// Connect to PeerJS, have server assign an ID instead of providing one
var peerID = prompt('What would you like your screen name to be?');
var peer = new Peer(
peerID,
{key: 'mypeerjsserverkey', debug: true},
{
config: {'iceServers': [
{url: stun.url},
{url: turn1.url, credential: turn1.credential, username: turn1.username},
{url: turn2.url, credential: turn2.credential, username: turn2.username}
]
}
});
NOTE: My ident, secret, domain, etc. obviously aren't accurately represented here. I don't think that's where my problem is.
Any thoughts?
If you email us a wireshark capture of your STUN/TURN traffic, we should be able to outline where your problem is. Messages sent over signalling are separate but parallel to WebRTC messages. Therefore, if the app is working but the messages are being sent over signalling, then it's possible the configuration of the application isn't correct.
XirSys provides TURN via UDP over TCP through port 80/443, so if the signalling is connecting and flowing, so should the TURN.
Also, looking at your code, if you pass data.d from your getIceServers success handler to the PeerJS config, that should reduce your code quite a bit :-) The ICE string you're reconstructing doesn't need to be broken down.
Regards,
Lee
XirSys CTO