Connect node opcUA client to server with different endpoint name - node-opcua

I have an nodejs application where I connecto to devices via opcUA and send data via websocket to web page which works fine so far...but now I want to add a device where the server ip and the available endpoint is different.
The server ip is opc.tcp://192.168.5.65:4840 and the endpoint is opc.tcp://proto-01:4840.
I can connect to the server, read and console.log the available endpoint but when I try to create a session I get the error: endpoint opc.tcp://192.168.5.65:4840 does not exist.
I can connect to the device with UA-Expert without any problems but get the message that the naming was changed to proto-1.
Does anybody know how to convince node opcua to connect to endpoint? I haven't found anything related to such a problem.

Related

GET of JWKS_URI is failing when using angular-oauth2-oidc library

I am using angular-oauth2-oidc to connect to Keycloak server which is behind nginx.
I am using code flow for retrieving the token.
Even when using HTTP also, I see a GET request being sent for /protocol/openid-connect/certs
which is failing since the frontend APIs are having the correct hostname, but the backend APIs (jwks_uri) is having localhost.
Also, I am unable to set the KC_HOSTNAME_STRICT_BACKCHANNEL=true since the backend microservices will not be able to connect to Keycloak.
Is there a workaround for this.

where to include credentials to connect to a websocket server in postman?

How do i connect to a server that uses sockets in postman? I can't understand where I should include the necessary data for the connection like the password, user, id and the port, I was able to connect to the server using a desktop application supplied with the server, by entering the previous data.

Postgresql requests proxied by HTTP server

I am using a mobile application that connects directly to the database instance (Postgres), as such, I have to keep the ports open for traffic that is generated from the internet (4G, mobile app).
This mobile app (QFIELD, mobile version of QGIS) has a direct connection to the database, this is the reason why the database is reachable from the internet on a public ip but this is a critical issue for the security of the data and the requests that can be sent to the database.
I would like to proxy the requests so that the database is only available to local machines and not open for connections directly.
The mobile appp would send the request to an HTTP url which would send the request to the local ip and port, this way I would avoid to have the database exposed on the internet.
Ideally, I would like to go from this app (which uses a postgres connection string to connect to the server) to an HTTP server that routes the request locally, as such:
APP connects to https://myproxy/postgres
Request is proxied to a local server
Can I do this with Apache2? Any ideas?
At the moment I cannot write a middleware that proxies requests from the APP to the local postgres.
If your application is expecting to connect directly to a PostgreSQL database and you don't want to change that then you need to connect to something that "speaks" PostgreSQL's client protocol.
You can place a proxy such as pgbouncer or pgpool in front of it, but they aren't a guarantee of greater security just by themselves. This is the same problem as with any proxy - it is just forwarding requests and responses to your actual server so any vulnerability is still exposed.
What you can do is:
restrict the number of connections at the proxy point
restrict which users can connect non-locally to your PostgreSQL cluster
restrict where they can connect from to just your proxy
restrict those users permissions within the database(s)
That last point is particularly important - assume any user account your application can be used maliciously. Restrict the account to prevent mass updating or deleting of data. Also take special care to restrict access to other users' data.
If I was forced to allow access like this, I would want one PostgreSQL user account per actual user at the very least. In practice I wouldn't get to this point with a production application.

While connecting two app servers with an ibm http webserver, we are able to successfully connect with only one server

While running two app servers (which has mobilefirst servers hosted 7.1 version) from ibm http server, only one server runs successfully on keeping only one of the Route attribute active in the plugin-cfg.xml of the http server. In the server which is not running, the following error is seen in the messages.log.
CWWKS4001E: The security token cannot be validated. This can be for the following reasons
1. The security token was generated on another server using different keys.
2. The token configuration or the security keys of the token service which created the token has been changed.
3. The token service which created the token is no longer available.
Kindly guide in resolving the error above.
Thanks.
Sounds like your two servers have not exchanged/shared LTPA keys and IHS and the WAS Plugin are a red herring.
http://www.ibm.com/support/knowledgecenter/SSAW57_liberty/com.ibm.websphere.wlp.nd.doc/ae/twlp_sec_ltpa.html
http://www.ibm.com/support/knowledgecenter/SSAW57_liberty/com.ibm.websphere.wlp.nd.doc/ae/twlp_sec_sso.html
Note: For SSO to work across Liberty servers, full profile servers, or both, set the following resources:
The servers must use the same LTPA keys and share the same user registry.
Sounds like communication issue between two servers. Are the inbound ports opened on another server to communicate with HTTP server? if they are opened use telnet and test whether both servers (HTTP and app server) are communicating with each other.
On HTTP Server, open command prompt and enter below command.
telnet <app server ip> <app server port>
If this is not successful then you need to open ports on app server.

Can't Authenticate with Local .NET back-end

I've followed the guide:
Getting Started with Authentication with Mobile Services .NET for Windows Store
I'm able to run the service locally as long as I don't need to authenticate the user. I can also authenticate the user if I publish the service to Azure. But I want to be able to test and authenticate the user locally. How can this be done?
I'm using Live ID and I have the correct ClientID and ClientSecret set in the Web.config. When I attempt to call LoginAsync from the client the call fails with The request could not be completed. (Method Not Allowed)
** Update 2014-03-20 **
Based on the comments of Carlos and Henrik, I've updated my local service to look exactly like my server instance. I followed Scot Hanselmans excellent guide and now I have my service running locally on port 80 and port 443 with a completely valid SSL certificate. It's even running on the exact same https://xxxx.azure-mabile.net hostname.
With these changes, there is now no configuration difference whatsoever between running the app against my local machine or running it against Azure. I can go to https://xxxx.azure-mabile.net in the browser, get redirected to Live login, sign in, and get redirected back to the service successfully. In the browser it all works. However it still doesn't work in the app.
I attached the debugger, set CLR errors to "break when thrown" and I managed to trap the exception in the service. Here's what I see in the immediate window:
The Response property is not helpful. It does not provide any additional information about the problem.
The only thing that stands out to me is that the app is trying to do a POST to /login/microsoftaccount while the browser would normally be doing a GET at this address (then getting redirected).
** Update #2 2014-03-20 **
After following Henriks guide for remote debugging I was able to load symbols and get a tiny bit more information:
"An existing connection was forcibly closed by the remote host"
The error code is 10054 (WSAECONNRESET) Connection reset by peer.
It appears the Live Authentication server may be forcibly terminating the connection, but only when I'm authenticating with the app. Again, authentication within the browser is fine. This, combined with the fact that /login/microsoftaccount is a POST from the app seems to suggest there is a problem with the authentication token I'm getting back from LiveClient.LoginAsync. I'll do some more digging...
At the moment, it is set up so that you don't need authentication when running locally and access the service from localhost. In this case, anonymous access is let through (this is of course disabled while running in the cloud).
We don't really have a way for your to authenticate locally as redirect URIs won't work (they can't point to localhost as there is not way that Facebook, say, can resolve "localhost").
One option is that we somehow can mock the authentication locally and give you a token without connecting with the various identity providers. I am not sure exactly what that would look like but it is something we can consider.
Henrik
Did you perhaps set Mobile client app: Yes in your Live Connect project? I think that setting is meant to be used with the Live Connect SDK (client) flow, not the browser-based (server) flow. The client flow isn't supported yet with a .NET backend.
You also want to make sure you are using LoginAsync(MobileServiceAuthenticationProvider.MicrosoftAccount) on the client to trigger the server flow.