We are creating a simulator to test our new system. The simulator will be used for performance testing using varying payloads. But we are stuck while trying to create multi-user scenario due to an embedded functionality of our new system. Given below is the workflow of the new system under question:
User logs in the system
When page is loaded, a hidden iFrame is rendered with url to User Authentication Service via HTTP Post
User Authentication Service executes a javascipt in the user browser and gets the following - (A) User ID, (B) IP Address, (C) Browser details
User is authenticated and next page is loaded
The javascript mentioned above is maintained by external group and we don’t have access to it (don’t have the source code yet but we may get it).
Our Scenario: We have to simulate multi user condition for varying pay load. We have created a simulator for this purpose. We want to simulate for different concurrent users connecting from different machines (different IP, browser). Since we are talking about simulated condition, the simulator is expected to generate it from the server machine only.
Challenge: How wan we suppress the execution of the javascript mentioned in the Step#3 above? Is it possible at all? What do we need to know from the external group regarding the javascript to achive it? Will it help, if we have the source code of the javascript?
Please refer to the image for the scenario mentioned here. Any help is appreciated:
Related
I have two Bokeh apps (on Ubuntu \ Supervisor \ Nginx), one that's a dashboard containing a Google map and another that's an account search tool. I'd like to be able to click a point in the Google map (representing a customer) and have the account search tool open with info from the the point.
My problem is that I don't know how to get the data from A to B in the current framework. My ideas at the moment:
Have an event handler for the click and have it both save a cookie and open the account web page. Then, have some sort of js that can read the cookie and load the account.
Throw my hands up, try to put both apps together and just find a way to pass it in the back end.
The cookies idea might work fine. There are a few other possibilities for sharing data:
a database (e.g. redis or something else, that can trigger async events that the app can respond to)
direct communication between the apps (e.g. with zeromq or similiar) The Dask dashboard uses this kind of communication between remote workers and a bokeh server.
files and timestamp monitoring if there is a shared filesystem (not great, but sometimes workable in very simple cases)
Alternatively if you can run both apps on the same single server (even though they are separate apps) then you could probably communicate by updating some mutable object in a module that both apps import. But this would not work in a scale-out scenario with more than one Bokeh server running.
Any/all of these somewhat advanced usages, an working example would make a great contribution for the docs so that others can use them to learn from.
I am developing a web application using Facelets and Entity-Controller-EJB structure. In the application, there are contents which are reachable only if you are logged. A bean checks the login state every time you click on a button/link for the restricted contents, and redirects you either to the selected page or to the login page.
I thought that this way is not safe, as you can write the link directly in the browser instead of generating it from a button that checks the bean. So what should I do? Is there a render option embeddable in each page or should I write a javascript function? In this case, what should I do? I have studied js fundamentals but don't really know how to implement this control!
Thank you for reading!
You cannot rely only on frontend to deny access to some parts of a web application.
This because all the HTML/CSS/Javascript is downloaded on users' browser, so they can read your code and your authentication mechanism, and understand how to bypass it (or just disable it).
More on this: Why are browsers allowed to display client-side source code?
What you need is implementing some security mechanism in the backed.
The simplest one is to delegate this to your webserver (here the instructions for Apache) and then use something similar to this to do login.
Another way is to have a proper backend: you send data to it (email/password) and it provides you a token that you use to access protected resources.
Or also, dinamically create your documents on server side, only if the user is authenticated.
Situation
I'm building a little chat using Symfony2. I'm wondering if there are possibilities to make the chat usable in offline mode. I'm not expecting to actively chat with connected user. I'm planning to make the user able to write message in offline mode (in the metro for instance), and then send it when connection is back again. Important: I would like to compute in the fact that connection can be gone for a long time. I remember beeing with people working in the Eurostar (Paris - London) and using their computers/phone while in a submarine tunnel for an hour or so. There was no connection at all. So in this case, how can you store a message for such a long time before sending it?
Problem
I found some interesting tutorial defining the HTML 5 offline mode. They define the capabilities of this offline mode with sending message but doesn't give example. Moreover, it seems that the only stuff we can put in the manifest are static files (css, javascript, html, pictures...)
My question is then, how do you store the written message from the user after she/he pressed the "send" button and is offline? Is it a javascript variable? Or is there html 5 features that exist?
Cheers!
You can do this via HTML5 local storage:
http://www.redrobotzoo.com/posts/html5-local-storage-and-local-databases-tutorial/
This example has very nice examples so it should not be a problem for you to make it work.
I'm building a website that is functionally similar to Google Analytics. I'm not doing analytics, but I am trying to provide either a single line of javascript or a single line iframe that will add functionality to other websites.
Specifically, the embedded content will be a button that will popup a new window and allow the user to perform some actions. Eventually the user will finish and the window will close, at which point the button will update to a new element reflecting that the user completed the flow.
The popup window will load content from my site, but my question pertains to the embedded line of javascript (or the iframe). What's the best practice way of doing this? Google analytics and optimizely use javascript to modify the host page. Obviously an iFrame would work too.
The security concern I have is that someone will copy the embed code from one site and put it on another. Each page/site combination that implements my script/iframe is going to have a unique ID that the site's developers will generate from an authenticated account on my site. I then supply them with the appropriate embed code.
My first thought was to just use an iframe that loads a page off my site with url parameters specific to the page/site combo. If I go that route, is there a way to determine that the page is only loaded from an iframe embedded on a particular domain or url prefix? Could something similar be accomplished with javascript?
I read this post which was very helpful, but my use case is a bit different since I'm actually going to pop up content for users to interact with. The concern is that an enemy of the site hosting my embed will deceptively lure their own users to use the widget. These users will believe they are interacting with my site on behalf of the enemy site but actually be interacting on behalf of the friendly site.
If you want to keep it as a simple, client-side only widget, the simple answer is you can't do it exactly like you describe.
The two solutions that come to mind for this are as follows, the first being a compromise but simple and the second being a bit more involved (for both you and users of your widget).
Referer Check
You could validate the referer HTTP header to check that the domain matches the one expected for the particular Site ID, but keep in mind that not all browsers will send this (and most will not if the referring page is HTTPS) and that some browser privacy plugins can be configured to withhold it, in which case your widget would not work or you would need an extra, clunky, step in the user experience.
Website www.foo.com embeds your widget using say an embedded script <script src="//example.com/widget.js?siteId=1234&pageId=456"></script>
Your widget uses server side code to generate the .js file dynamically (e.g. the request for the .js file could follow a rewrite rule on your server to map to a PHP / ASPX).
The server side code checks the referer HTTP header to see if it matches the expected value in your database.
On match the widget runs as normal.
On mismatch, or if the referer is blank/missing, the widget will still run, but there will be an extra step that asks the user to confirm that they have accessed the widget from www.foo.com
In order for the confirmation to be safe from clickjacking, you must open the confirmation step in a popup window.
Server Check
Could be a bit over engineered for your purposes and runs the risk of becoming too complicated for clients who wish to embed your widget - you decide.
Website www.foo.com wants to embed your widget for the current page request it is receiving from a user.
The www.foo.com server makes an API request (passing a secret key) to an API you host, requesting a one time key for Page ID 456.
Your API validates the secret key, generates a secure one time key and passes back a value whilst recording the request in the database.
www.foo.com embeds the script as follows <script src="//example.com/widget.js?siteId=1234&oneTimeKey=231231232132197"></script>
Your widget uses server side code to generate the js file dynamically (e.g. the .js could follow a rewrite rule on your server to map to a PHP / ASPX).
The server side code checks the oneTimeKey and siteId combination to check it is valid, and if so generates the widget code and deletes the database record.
If the user reloads the page the above steps would be repeated and a new one time key would be generated. This would guard against evil.com from page scraping the embed code and parameters.
The response here is very thorough and provides lots of great information and ideas. I solved this problem by validating X-Frame-Options headers on the server-side , though the support for those is incomplete in browsers and possibly spoofable.
I wrote a web page that displays images from several servers on my network via simple img tags with appropriate href values. The servers require authentication before they will send the images.
It works alright, except on first load the page presents the user with a series of password prompts (one for each server). The user can select the "Remember my password" checkbox, and then subsequent refreshes of the page work without prompting, with correctly updated images. That is, until someone closes out the browser, after which a new set of prompts awaits anyone who opens the page again.
All of the credentials needed are known beforehand, and I don't care if someone could read them in the page source, since this page is in a protected part of an internal intranet site. Everyone with access to this page knows the passwords anyway.
The only browser we're allowed to use is IE 7, so I don't care about compatibility with other browsers at the moment.
Is there any way I can use JavaScript (or some other client-side code) to automatically answer those prompts so the user never sees them?
Thanks very much, in advance.
You can include the authentication in the URL:
<img src="http://paulfisher:tastybacon#internalwebs/path/to/image.png">
Where, of course, paulfisher is my username and my password is tastybacon.
No, javascript can't do this. Here are a couple of options that I've used before to solve this problem:
Change the authentication on the other servers to be either anonymous or integrated.
Proxy in the images: On the server serving the page, add another page that takes in the URL of the remote server. This new page makes a webrequest to the other server and streams the image back. The webrequest can plug in the correct credentials.
Depending on the servers' DNS names, it might be possible to share an authentication cookie across all of the servers. Then you could set up some kind of module on all of the servers to allow the shared authentication.