I try to make my web application work with WebSocket and while implementing the front-ent javascript I am requested to give the server url as an argument (e.g var exampleSocket = new WebSocket("wss://www.example.com/socketserver", "protocolOne");). However, I still don't know on which exact domain name my server will be run at and I want my back-end to work versatility without depending on me updating it. Note that the server side script that runs the WebSocket server is the same that runs the Express server to serve the page, the this file is located in the same path with a folder contains all the front-end statics (including the script.js). Any advice on how to implement this?
The answer is probably to use:
var exampleSocket = new WebSocket(`wss://${window.location.host}/`,"protocolOne");
Related
For example is it safe to put this in my .js file that's client side.
Parse.initialize("myAppId");
Parse.serverURL = 'https://0fc98698cc.ngrok.io/1'
Yes, as the docs say, it is safe to use the YOUR_APP_ID, YOUR_JAVASCRIPT_KEY and YOUR_PARSE_SERVER URL on the client side, but NOT the YOUR_MASTERKEY.
Parse.initialize("YOUR_APP_ID", "YOUR_JAVASCRIPT_KEY", "YOUR_MASTERKEY");
//javascriptKey is required only if you have it on server.
Parse.serverURL = 'http://YOUR_PARSE_SERVER:1337/parse'
It is totally safe to expose your APP_ID and SERVER_URL. App ID only identify your parse applications if you are hosting more than one parse app on your node process. For instance, if you are mounting more than 1 parse server to an express application, you use different app ids and mounting points.
I have a web site I'm developing that uses IdentityServer3 to authentication with, and it also returns an access token to enable access to my APIs. All works well. I'm now rewriting the web site into a standalone windows EXE. The EXE is written in React and Electron to make it a standalone application. My problem is: I call the 'authorize' endpoint to my identityserver3 server, but I do not know what to put in for the 'redirect_uri' required by identityserver3? Since my EXE is standalone it has no uri address?
Is there a way to use IdentityServer3 as an API, where I can send the 'authorize' url to IdentityServer3, and have it return the access token as a response (to the API call?)
You can do as Kirk Larkin says - use the Client Credentials flow.
The following code is in .NET:
var client = new TokenClient(
BaseAddress + "/connect/token",
"clientId",
"clientSecret");
var result = client.RequestClientCredentialsAsync(scope: "my.api").Result;
var accessToken = result.AccessToken;
Where BaseAddress is your IDS address.
Of course you will have to register your client in the IDS clients list with the appropriate flow (Client Credentials), and the scope is just optional, but I guess you will need one.
Then accessing a protected API is fairly easy:
var client = new HttpClient();
client.SetBearerToken(accessToken);
var result = client.GetStringAsync("https://protectedapiaddress").Result;
EDIT: For JavaScript approach:
This and this look like a working solution, but I've tried neither of them
I have a python flask app running on my server:
if __name__ == '__main__':
port = int(os.environ.get("PORT", 6600))
app.run(host='0.0.0.0', port=port)
And I have a JS script getting information from that app, I don't want to change manually th IP or domain in the JS script every time I deploy or change the domain so I'm asking is there any way for the JS to know the IP or hostname of the python app ?
Here's my structure:
index.py <= main app
static
**index.html
**script.js
Thanks
Register a domain name and stick with it. Use the domain name in your javascript and/or config.
Make sure that the registrar provides an interface for updating the "A record" (IP address) and point it at your server. Whenever you change IP address, update the A record for your domain.
If I understand your question correctly, you pretty much have two options at your disposal depending on your setup.
Option 1: If your JavaScript code is running on the same machine as your Python script, you could simply always just access it from 127.0.0.1 from your JavaScript code (because binding to 0.0.0.0 will make the Python server accessible from all interfaces, including the loopback interface at 127.0.0.1).
Option 2: If your JavaScript code lives on a remote server, your simplest solution is going to be to use some kind of Dynamic DNS service as an intermediary. So you'll end up with two domains for your Python server: one static one available to the rest of the world, like www.mypythonserver.com, and one dynamic DNS entry only known by your JavaScript code, like mypythonserver.noip.me (hard-coded permanently into your JavaScript code). Both of these domains should always resolve to your Python server's host address, with no manual intervention necessary for the dynamic DNS entry.
You can use the templating in the script file which would get filled with the port number when user requests the script.
There are many templates available at :
https://wiki.python.org/moin/Templating
Usually it would be like
// in script.js
var myport = {{ port }};
and in your python code :
# if request is for script.js
# respond with template
request.send(my_templating_engine('script.js' , port))
I'm trying to use two websockets on one page. This is my code:
var pageViewWs = new WebSocket("ws://localhost:9002/pageView");
var sessionWs = new WebSocket("ws://localhost:9002/session");
pageViewWs.onmessage = function (event) {
alert("PageView");
};
sessionWs.onmessage = function (event) {
alert("Session");
};
Only the PageView alert appears. On the server side no requests are made to /session, only to /pageView.
Now, if I switch var pageViewWs and var sessionWs around then the Session alert is shown instead of the PageView. It is not because they are alerts, I've tried appending to the body and to divs and I've stepped through using Firebug. It seems that only one WebSocket can be created at a time although in Firebug the properties for pageViewWs and sessionWs appear the same with the exception of their url.
I've only tested this in Firefox 15.0.1. Is there some sort of Websocket limitation whereby you can only run one at a time? Or is something wrong with my code?
I faced the same problem to run multiple services through the same port. So, I created a PHP library to do this.
Why ?
Some free plans of hosting providers don't allow you to bind to ports or allow you to bind to one port. In case of OpenShift Cloud Server, you can only bind to port 8080. So, running multiple WebSocket services is not possible. In this case, Francium DiffSocket is useful.
You can run different services on the same port using a PHP library called Francium DiffSocket.
After setting up Francium DiffSocket, you can do this for using different services :
var chatWS = new WebSocket("ws://ws.example.com:8000/?service=chat");
var gameWS = new WebSocket("ws://ws.example.com:8000/?service=game");
An example are these services which are running through a single port :
Finding Value Of Pi
Advanced Live Group Chat With PHP, jQuery & WebSocket
Live Group Chat With PHP, jQuery & WebSocket
I believe you can only create one WebSocket connection from a client to a specific port on the host. Have you tried either running the two services on different ports, or on different servers? This would allow you to determine the limitation...
Apart from the HTTP Request head both the request are the same. They hit the same application server on the same port. It is up to the server side application to treat each connection differently based on the HTTP request that initiated it.
I've done this in node. You could do it manually but packages like
espress-ws
or express-ws-routes
eases the process.
I've got a production site that has been working for years with a SQL Server 2000 default instance on server named MDWDATA. TCP port 1433 and Named Pipes are enabled there. My goal is to get this web app working with a copy of the database upgraded to SQL Server 2008. I've installed SQL2008 with SP1 on a server called DEVMOJITO and tested the new database using various VB6 desktop programs that exercise various stored procs in a client-server fashion and parts of the website itself work fine against the upgraded database residing on this named instance of SQL2008. So, while I am happy that the database upgrade seems fine there is a part of this website that fails with this Named Pipes Provider: Could not open a connection to SQL Server [1231]. I think this error is misleading. I disabled Named Pipes on the SQL2000 instance used by the production site, restarted SQL and all the ASP code still continued to work fine (plus we have a firewall between both database servers and these web virtual directories on a public facing webserver.
URL to my production virtual directory which demos the working page:
URL to my development v-directory which demos the failing page:
All the code is the same on both prod and dev sites except that on dev I'm trying to connect to the upgraded database.
I know there are dozens of things to check which I've been searching for but here are a few things I can offer to help you help me:
The code that is failing is server-side Javascript adapted from Brent Ashley's "Javascript Remote Scripting (JSRS)" code package years ago. It operates in an AJAX-like manner by posting requests back to different ASP pages and then handling a callback. I think the key thing to point out here is how I changed the connection to the database: (I cannot get Javascript to format right here!)
function setDBConnect(datasource)
{
var strConnect; //ADO connection string
//strConnect = "DRIVER=SQL Server;SERVER=MDWDATA;UID=uname;PASSWORD=x; DATABASE=StagingMDS;";
strConnect = "Provider=SQLNCLI10;Server=DEVMOJITO\MSSQLSERVER2008;Uid=uname;Pwd=x;DATABASE=StagingMDS;";
return strConnect;
}
function serializeSql( sql , datasource)
{
var conn = new ActiveXObject("ADODB.Connection");
var ConnectString = setDBConnect(datasource);
conn.Open( ConnectString );
var rs = conn.Execute( sql );
Please note how the connection string differs. I think that could be the problem but I don't know what to do. I am surprised the error returned says "named pipes" was involved because I really wanted to use TCP. The connection string syntax here is the same as used successfully on a different part of the site which uses VBScript which I'll paste here to show:
if DataBaseConnectionsAreNeeded(strScriptName) then
dim strWebDB
Set objConn = Server.CreateObject("ADODB.Connection")
if IsProductionWeb() Then
strWebDB = "DATABASE=MDS;SERVER=MDWDATA;DRIVER=SQL Server;UID=uname;PASSWORD=x;"
end if
if IsDevelopmentWeb() Then
strWebDB = "Provider=SQLNCLI10;Server=DEVMOJITO\MSSQLSERVER2008;Database=StagingMDS;UID=uname;PASSWORD=x;"
end if
objConn.ConnectionString = strWebDB
objConn.ConnectionTimeout = 30
objConn.Open
set oCmd = Server.CreateObject("ADODB.Command")
oCmd.ActiveConnection = objConn
This code works in both prod and dev virtual directories and other code in other parts of the web which use ASP.NET work against both databases correctly. Named pipes and TCP are both enabled on each server. I don't understand the string used by the Pipes but I am using the defaults always.
I wonder why the Javascript call above results in use of named pipes instead of TCP. Any ideas would be greatly appreciated.
Summary of what I did to get this working:
Add an extra slash to the connection string since this is server-side Javascript:
Server=tcp:DEVMOJITO\MSSQLSERVER2008,1219;
Explicitly code tcp: as a protocol prefix and port 1219. I learned that by default a named instance of SQL uses dynamic porting. I ended up turning that off and chose, somewhat arbitrarily, the port 1219, which dynamic had chosen before I turned it off. There are probably other ways to get this part working.
Finally, I discovered that SET NOCOUNT ON needed to be added to the stored procedure being called. Otherwise, the symptom is the message: "Operation is not allowed when the object is closed".