I feel that Qt's WebSocket implementation does not care about what path you send to connect to the server, so that there is no distinguishing between, say:
ws://localhost:1234/chatroom
and
ws://localhost:1234/echotest
Is this (URI path parsing) supported by QWebSocketServer?
After some digging I found it is, but not via a direct API call.
When a connection is established, we are able to obtain the URL of the request, by socket->requestUrl(), then we can respond according to what url the request sent.
Related
I want to send SMS from AngularJS web application using Ozeki sms gateway. Can anyone tell me how to do this? pr suggest me some reference link or code sample.
Plain sending
Assume we skipping other protocols available inside Ozeki Sms NG product (like SMPP, Email, DB etc), and getting to HTTP protocol only, you can go this way:
Prerequisites:
Figure out best way for you to make HTTP request to send SMS
(I'm not AngJS guy so may be there are already few ways to make HTTP-request from Angular, but at least any Ajax method passing params to executing PHP-script for making HTTP request (with curl, file_get_contents) will be totally Ok).
Make sure your Ozeki SMS server is reacheable via IP/domainname etc by your PHP-script so your code can reach its endpoint.
Doing it:
Inside Ozeki install service provider like HTTP Client
http://www.ozekisms.com/index.php?owpn=195&info=service-provider-connections/http-client-connection
or HTTP Server (more powerful version of HTTP Client allowing call back URLs)
http://www.ozekisms.com/index.php?owpn=197&info=service-provider-connections/http-server-connection
Then according (to docs) execute request like
http://server_ip:9501/api?action=sendmessage&username=________&password=________&originatior=__________________&recipient=__________________&messagetype=SMS:TEXT&messagedata=______________
*Some fields are not necessary, it may vary depending on Ozeki version you use.
** port 9501 - is a default Ozeki HTTP port which may be changed in general settings, also it has HTTPS port as well. Basically the correct port is the same which you already use when accessing Ozeki Web GUI.
After executing sending request (try from browser or from something like Postman first) you should get responce in XML format informing you about result of your transaction.
Possible next step... DLRs
Getting delivery reports (if supported by your operator) is a common "i want it too" question.
In case you need them - there is great embedded feature inside "HTTP Server" connector (mentioned above).
Here you can see more details
http://www.ozekisms.com/index.php?owpn=431
"reporturl" - is a field you may use to set kind of "call back url". In other words in this optional field you may specify full URL and list fields to be passed along. So you only have to create your own endpoint to catch them (as GET request from Ozeki server) and use inside your software.
I've got a (Spring) handler that I'd like users to be able to bookmark. As it's coded now, they get different formats (CSV, JSON) back based on the Accept header.
Would there be any way for users to specify the URL so that they can say what header they want? Or am I going to have to give URL-level parameter for the different formats?
Would there be any way for users to specify the URL so that they can say what header they want?
no there is no way to do that magically.
Or am I going to have to give URL-level parameter for the different formats? Yes this is valid
This is quoted from xml.com:
Server-driven negotiation. The service provider determines the right representation from prior knowledge of its clients or uses the information provided in HTTP headers like Accept, Accept-Charset, Accept-Encoding, Accept-Language, and User-Agent. The drawback of this approach is that the server may not have the best knowledge about what a client really wants.
Client-driven negotiation. A client initiates a request to a server. The server returns a list of available of representations. The client then selects the representation it wants and sends a second request to the server. The drawback is that a client needs to send two requests.
Proxy-driven negotiation. A client initiates a request to a server through a proxy. The proxy passes the request to the server and obtains a list of representations. The proxy selects one representation according to preferences set by the client and returns the representation back to the client.
URI-specified representation. A client specifies the representation it wants in the URI query string.
I am trying to use my proxy with the Soundcloud API. The format is
client = soundcloud.Client(client_id=client_id,
client_secret=client_secret,
username=username,
password=password,
proxies=proxies)
However, when I pass something into the proxies variable like
proxies = {'http': 'notavalidip'}
the client is still able to log in and function normally. Why is this happening and how can I test that when I pass an actual valid proxy it will actually be used? I believe this API uses the Python requests library, if that helps.
All those options get handed down to make_request eventually being passed into kwargs inside the request_func, which is indeed backed by the requests library.
Your proxy is passing only because it has the wrong scheme. All connections to Soundcloud are made via https, and not http by default. This means that you have no proxy setup, since your proxies dictionary has no https key.
See here how proxy is simply set to None because the dictionary didn't have the required scheme.
After modifying your proxies variable to https instead of http I got an exception thrown (ProxyError('Cannot connect to proxy.'), so no silent fails.
Hope this makes sense.
Is it ok to pass passwords like this or should the method be POST or does it not matter?
xmlhttp.open("GET","pas123",true);
xmlhttp.send();
Additional info: I'm building this using a local virtual web server so I don't think I'll have https until I put upfront some money on a real web server :-)
EDIT: According to Gumo's link encodeURIComponent should be used. Should I do xmlhttp.send(encodeURIComponent(password)) or would this cause errors in the password matching?
Post them via HTTPS than you don't need to matter about that ;)
But note that you need that the page which sends that data must be accessed with https too due the same origin policy.
About your money limentation you can use self signed certificates or you can use a certificate from https://startssl.com/ where you can get certificates for free.
All HTTP requests are sent as text, so the particulars of whether it's a GET or POST or PUT... don't really matter. What matters for security in transmission is that you send it via SSL (and handle it safely on the other end, of course).
You can use a self-signed cert until something better is made available. It will be a special hell later if you don't design with https in mind now :)
It shouldn't matter, the main reason for not using GET on conventional web forms is the fact that the details are visible in the address bar, which isn't an issue when using AJAX.
All HTTP requests (GET/POST/ect) are sent in plain text so could be obtained using network tracing software (e.g. Wireshark) to protect against this you will need to use HTTPS
I have a basic Squid server setup and I am trying to use Ruby's Net::HTTP::Proxy class to send a POST of form data to a specified HTTP endpoint.
I assumed I could do the following:
Net::HTTP::Proxy(my_host, my_port).start(url.host) do |h|
req = Net::HTTP::Post.new(url.path)
req.form_data = { "xml" => xml }
h.request(req)
end
But, alas, proxy vs. non-proxied Net::HTTP classes don't seem to use the proxy IP Address. my remote service responds telling me that it received a request from the wrong IP address, ie: not the proxy. I am looking for a specific way to write the procedure, so that I can successfully send a form post via a proxy. Help? :)
Hah, turns out that is the right way to do it, my issue was actually with Squid and the API I was pushing to. Interesting tip related to this problem, if you are proxying with Squid proxy server, you probably want to add this server config option:
header_access X-Forwarded-For deny all
This will make sure that the proxy completely ignores any relation to the caller's IP address as far as the HTTP endpoint is concerned.
You may also want to look at the mechanize gem, based on Perl's WWW::Mechanize. If it's anything like the Perl one (and I'm led to believe it is), then it encapsulates much of the common mess that you're dealing with.
Ruby: http://mechanize.rubyforge.org/
Perl: http://search.cpan.org/dist/WWW-Mechanize/