I'm working on a Windows 8 app, building it in HTML5/JavaScript. Part of the functionality in the app requires user authentication. The process in place is via a web form that posts the data back to a server side script and, upon successful authentication, returns a set of cookies. The data in these cookies can then be cached and used to perform several other API calls. I would like to use WinJS.xhr to do this instead of embedding the web page in the app.
First, I assume I can use the data parameter of the xhr method to pass the username and password information to the server-side script, but I'm not sure how to format that for a POST.
Second, if I can get the authentication piece to work, is there a way for me to see the cookie content returned in the HTTP response header?
You should be able to encode using the FORM encoding standard. I have some sample code that is intertwined in here, but it's very simple to encode it, and set the method to "POST" rather than GET.
For cookie transfer, you should be able to pull those out of the headers and set them as appropriate.
Related
I am using Jmeter in order to test a web application. The issue i am facing is that when i am running the recorded script. I cannot see the data getting added in the database or in the UI of the application.
I recorded a script in which i added the data but when i run it, the response code is 200 and i have added regular expression extractors wherever needed. But still with no luck.
While looking at the View Result Tree, I can even see the Response that data is getting added but not on UI or DB.
If your website is using cookies to handle user sessions, you must add to your Test plan HTTP Cookie Manager to save and send cookie in HTTP requests.
it stores and sends cookies just like a web browser. If you have an HTTP Request and the response contains a cookie, the Cookie Manager automatically stores that cookie and will use it for all future requests to that particular web site.
I need to call a web service from my client side JavaScript code (which will run as a web page is loading). I understand there are libraries for doing this like this one, or I can just use straightup jQuery as described here.
But one concern I had was authentication. I need to send the webservice a username/password or a authorization header as described here. Now if this will not come from the user, it seems that it needs to be stored somewhere on the browser side code in order for it to be sent when that code runs (client side).
Won't this then be in the clear for all to see just by doing a view source on my page? If so, how can I prevent this?
Well you can encode the user name and password so if someone sees the view source of the web page it will show the encoded credentials.
To encode/decode the credentials you can use the atob and btoa Javascript functions. They are present in the JavaScript implementation of most browsers. See this link: https://developer.mozilla.org/en/docs/Web/API/WindowBase64/Base64_encoding_and_decoding
When sending the credentials to the server you can decode the data before sending the credentials.
To ensure that the credentials are not read during transmission, they should not be sent in plain text. HTTPS can be used to secure the web service requests.
We have an application which is destined for https so the data being transmitted is protected (or should I say as protected as need be) I would like to know about protecting/hiding (or similar) queryString values. Its a jQuery/Javascript front end which communicates using a mixture of GET and POST with the database via classic ASP web services. The web services sends JSON back to the client.
I realize the front end code could be changed so everything is passed using POST however the application is finished and tested ready to deploy. There are some key values that are being passed in the querystring which should not have been. Is it possible to make it so the querystring values can not be inspected or sniffed. The URL and querystring together will provide a direct link to the raw JSON. We would like to prevent this. Perhaps there is some jQuery/AJAX feature which can be explored. Perhaps some server IIS level tactic? I guess the sniffing occur before the request gets the the server where the webservice sites therefore some server/IIS level tactic is not an option.
Any ideas/advice would be great, thank you.
You can use HTTP headers to send data to the server that is slightly less visible, but can still be detected using more advanced developer tools and loggers. For example, this answer descibes using jQuery/Javascript (as you've asked) to send data without using QueryString.
You can't really prevent the client from being able to trace these details though.
The solution I personally suggest to you is to look into session state. By scoping a valid data response to a certain session state, and returning null when the state is invalid or expired, you can limit access to the data. This could be after just 1 time its been retrieved. This strategy would involve a generation of a token or code that is passed out from your server at an earlier stage, and used when asking for the data in question.
Another alternative is to either use SSL or encrypt your data and drop it into a posted control such as a text input box. Microsoft adopted a similar process for their VIEWSTATE within ASP.NET.
I have a PHP app that renders HTML pages for a social media application that I'm creating. Then, JavaScript initializes and makes things interactive. The PHP side of things logs into a separate webservice with curl.
Now, I can't figure out a way to share the session started in PHP with JavaScript, so when I make a AJAX request in JavaScript to the data server, its authenticated.
Is there a way to share a PHP session with JavaScript? Or to share authentication initially created with PHP with JavaScript?
I would say it sounds like there is something wrong with your architecture. In my opinion, the web server itself, should be the only peer providing data to the client/browser. It's a two party conversation only.
When trying to hit a third-party server from the browser, you violate the browsers Same-Origin Policy, unless you specifically allow CORS by explicitly setting various request and response headers. - and you would only do so in very special situations.
The best solution might be to create proxy services at the web server, that can be hit directly (locally) by the browser. The web server can then (acting as controller) forward the data-request to the data server (model) and finally return the response to the browser (view).
You can read out the session cookie set by PHP (SID I guess) through JavaScript containing the session ID.
When you make a query, use
http://example.com/?sid=SessionID
I am newbie to angularjs. I developed an angularjs application using angular seed skeleton https://github.com/angular/angular-seed for client side. And for API server I used expressjs server.
My home page url is something like localhost:9000/app/index.html#/home
So, typically if I hit the url localhost:9000/app/index.html#/home I see my home page.
But, I have a requirement that there will be a POST request also to my application from some xyz application.
So, I want to determine, whether the incoming request to my angular seed application is coming from an external application or not.
Like in PHP there is a Super global array $_SERVER, with which you can determine the incoming request method... Is there anything in angularjs to determine the request method.
I hope my question is clear enough to understand.
Truly appreciate for reading my question, some hint would be great.
What you are asking implies you want to use an Angular frontend to provide POST method endpoints to your API. This does not make sense.
The equivalent of PHP's $_SERVER array to get passed variables is found inside Express's API, using the req parameter of a specific route setup. See http://expressjs.com/4x/api.html#router.route. This is where you create logic based on request method. app.get() and app.post() and app.put() and so on, as Ben's comment mentioned.
In the traditional PHP example you mention, the entire request goes to the server and a page result is returned to the browser, so you have the chance to detect that a POST or GET was made and direct the request appropriately.
Angular is a javascript based framework that runs in a browser. The browser will use GET requests to initially download all the html/js/css, but then it runs in a javascript context and no server is involved after this point unless explicitly coded in an Angular module/controller. This is where you would make GET/POST/PUT/DELETE requests to your API backend.
Your API is accessed with XHR (XmlHttpRequest) calls in a javascript context, based on user interaction with the UI. These calls can be made using GET or POST et al depending on how your API functions, using angular $http or $resource and the like.