Can I change PING information through Chrome browser in wss:// request? - google-chrome

My computer has an wss:// connection to some hardware which is controlling a climate system. I can use an interface to change values to my liking, but I want to be able to directly send this value myself through the wss:// connection, preferably directly in the Chrome browser. I have shown the example below, in which I would like to change fanSpeed to for example 60, but I cannot change this ping values in the browser. Is there any way to do so? For example in a POST request, Chrome allows for the values to be modified and send again. I find information on this topic scarce, and am completely new to the subject. Can this be done?

Related

how to hide hidden value from source code in html?

In my html I'm using hidden value as :<input type="hidden" value="secure" name="first"> but the problem is when I see in browser console value is displaying .How to hide this?
The browser belongs to the visitor. You can't give the browser anything without giving it to the visitor as well.
If you don't want to visitor to have access to data, then never give it to the browser in the first place.
Keep the data on the server and send the browser a session token instead.
You can't. The whole point of a client/server based setup, like 'the web' is by definition, is that everything you transmit to the client can be read by any client.
If you need to secure data from the end user, keep it on the server side. There are a myriad of possible solutions for this, like sessions, cookies and preshared keys, to sync serverside storage with the client.

How to create pop-up login box?

the box appears in below snapshot is neither alert box,prompt box nor confirm box. then what is this? how can i create the same thing like this?
It's a BasicAuth prompt, if your server return a request for BasicAuth it will get handled by the browser.
It happens when the browser receives a response with a header that looks like this, "insert realm" can be almost anything:
WWW-Authenticate: Basic realm="insert realm"
Usually the web browser handles it by itself and shows that kind of prompt. By the way it's unrelated to the web server as it's part of the protocole. If you happen to run an application server, you'll have to send the header above in a response and expect an Authorization header back from the "web client".
If you run apache, nginx, you can check simply for BasicAuth and you should be able to find documentation on how to set it up.
Read more here: BasicAuth
If you have enough courage you can read the RFCs
This is a simple HTTP Authentification, like the one you can setup with a ".htpasswd" file on Apache and so on.
You can't do it with Javascript (it's on server-side), in PHP it would be like this

Accessing redirected-to URL when making an HTTP request

When making an HTTP request (using URLLoader, for example) that results in a redirect, is it possible to access any of the URLs in the redirect chain?
For example, let's say that the following happens:
We make a request to example.com/a.gif
example.com redirects to example2.com/b.gif
example2.com redirects to example3.com/c.gif
I've stared at the documentation for URLLoader and its various events for a while, and it doesn't seem like there's a way to either:
Instruct URLLoader to not follow redirects
Access any of the URLs involved after the initial request
Does anyone know if there's a way to do this? I'm not attached to using URLLoader, so if there's another class that supports this functionality, I'd be fine with using it.
Can anyone point me in the right direction? Thanks in advance!
Edit - I should clarify: I know how to detect the redirects outside of AS3 using a DOM debugger. I'm specifically interested in accessing the redirect chain within AS3. It would appear that it's possible using the AIR player via the HttpStatusEvent, but the relevant properties aren't available when using Flash Player.
Edit 2 - I've also tried using an HTTP client lib (as3httpclientlib, to be specific). This works except for the fact that it loads cross-domain policies from port 843 rather than by making an HTTP request to /crossdomain.xml. The context I'm working in requires the latter, so using something with Socket underlying it won't work unless there's a way to force Socket to load cross-domain policies from HTTP instead of port 843.
The redirects are generally in place because the original URL shouldn't be used anymore. The file doesn't exist at example.com/a.gif so in theory you don't need to know about it. Why do you need the intermediate request path?
I'm not aware of an actionscript way of finding the redirect chain for any request, but if you want to do it for a specific chain you can use HttpFox for Firefox, or hit f12 in google chrome and look at the network tab when making a request to the URL that redirects. This will only work if the client is redirected by the server to the new address (a HTTP 302 responce or similar.) If the server chooses to return the contents of example3.com/c.gif when someone's browser asks for example.com/a.gif there is nothing you can do.

how to reverse engineer an http API call using REST console

I'm trying to replicate a request I make on a website (ie zoominfo.com) using the same http POST parameters using chrome rest console, but it fails for some reason. I'm not sure if there is a missing field or it's not working because the origin of the request isn't valid.. can someone point me out in the right direction? Below is a detailed explanation of the experiment:
ORIGINAL CASE
basically if I go to zoominfo.com (registered and all) I see a form page that I need to fill:
if I hit enter.. the site makes an ajax call. If I open the chrome web dev tools, and open the network tab, I see the details of the ajax call:
notice the body of the POST has the name John Becker in it:
{"boardMember":{"value":"Include","isUsed":true},"workHistory":{"value":"CurrentAndPast","isUsed":true},"includePartialProfiles":{"value":true,"isUsed":true},"personName":{"value":"john%20becker","isUsed":true},"lastUpdated":{"value":0,"isUsed":true}}
the response is shown under the respones tag:
WHAT I'M TRYING TO DO
basically replicate what i've done above using a REST console (note: so there is nothing illegal here.. i'm just replacing a chrome browser action with a rest client action.. i'm not hacking anyone and i'm not getting information I can't get the normal way, but if someone feels otherwise.. please let me know)..
so I plug in the same parameters as above into the rest console:
now i'm not sure about authentication.. but just to be safe, i entered the same user name and pwd i have for the site into the REST console:
but then I keep on getting an error as a response to my rest console's request:
UPDATE: CORRECT ANSWER:
so according to JMTyler's answer.. I had to simply include criteria in the RAW body, and convert it to url encoding.. in addition to that, I had to explicitly set the encoding in the rest console body..
looking at the chrome inspector more closely, it turns out that I simply had to click on view source:
to get the url-encoded value that I needed to put in the RAW body in the rest console:
I also had to set encoding to gzip,deflate,sdch and things worked fine!
The form is posting all that JSON under the field criteria. You can see this in the screencap of the chrome dev console you posted.
Just start your raw body in rest console with criteria= and make sure the json has been url-encoded. That should do it.
No authentication is needed because none is passed through the headers in your screencap. Any cookies you have when you load the page normally will also be loaded through rest console, so you don't need to worry about explicitly setting them.
Reading your problems I'll make an educated guess:
zoominfo does not provide an RESTful API.
Rest-Console understands and uses HTTP Authentication, which is different from the authentication handler zoominfo implemented.
A possible way to work around may be:
Make a call to the login-page via rest console. you'll get back cookies and a lot more.
In subsequent requests to zoominfo be sure to include those cookies (likely holding some session information) in your request, therefore acting like a browser.

Testing PUT methods on a RESTful web service

I have a simple RESTful web service and I wish to test the PUT method on a certain resource. I would like to do it in the most simple way using as few additional tools as possible.
For instance, testing the GET method of a resource is the peak of simplicity - just going to the resource URL in the browser. I understand that it is impossible to reach the same level of simplicity when testing a PUT method.
The following two assumptions should ease the task:
The request body is a json string prepared beforehand. Meaning, whatever is the solution to my problem it does not have to compose a json string from the user input - the user input is the final json string.
The REST engine I use (OpenRasta) understands certain URL decorators, which tell it what is the desired HTTP method. Hence I can issue a POST request, which would be treated as a PUT request inside the REST engine. This means, regular html form can be used to test the PUT action.
However, I wish the user to be able to enter the URL of the resource to be PUT to, which makes the task more complicated, but eases the testing.
Thanks to all the good samaritans out there in advance.
P.S.
I have neither PHP nor PERL installed, but I do have python. However, staying within the realm of javascript seems to be the simplest approach, if possible. My OS is Windows, if that matters.
I'd suggest using the Poster add-on for Firefox. You can find it over here.
As well as providing a means to inspect HTTP requests coming from desktop and web applications, Fiddler allows you to create arbitrary HTTP requests (as well as resend ones that were previously sent by an application).
It is browser-agnostic.
I use the RESTClient firefox plugin (you can not use an URL for the message body but at least you can save your request) but also would recommend curl on the command line.
Maybe you should also have a look at this SO question.