I have a challenge that I can't solve. I have made a website with node.js and have all of the code written for the routing including routing for sub-domains. Some location only some users can access, some locations only logged in users can access. I wanted to include a chat for my users so I went along and created one with socket.io and some client side js.
Now I need the site to keep the chat element open which in on a bar across the screen when the client goes to another portion of the website. I have looked into many solutions but almost all of them include some js library like angular.js with the ng-model or ui technique but all include writing code for the client side that handles the url and what to load.
I don't really want to do this method because:
I don't want to re-write all my routes and I am not even sure how to handle the authentication of the users.
I find the client method to be a security issue
My website isn't a single page app, I just want one portion of the website to stay loaded.
Here is some images of what I am wanting:
State 1:
State1
State 2:
State2
Notice that the chat stays but other content was loaded. Also that it went to a different sub domain and a location that is only accessible by logged in users.
Thanks!
I guess you want to maintain state across page refresh, much like e.g. Facebook does. A true and trusted way of doing this is setting a cookie that stores the chat state: open/closed, or store the state on the server. Then on page load, initialize the chat based on this data.
Related
We have to implement a mechanism to protect content on our main www.oursite.com. We also have AMP pages being served from amp.oursite.com. Finally, the AMP pages are also getting served from the Google cache via https://www.google.com/amp/s/amp.oursite.com/
The mechanism that we want to implement is similar to a freewall which requires users to register and once they do, they will have access to most of the content on the website.
Registration and login happens on a subdomain such register.oursite.com.
We envisage a typical flow would be as follows:
User finds a page while performing a search on their mobile device via a Google search results.
They click on search result and are taken to the page on the google.com domain.
A pop-up or modal window (served over register.oursite.com) appears over the page with protected content asking them to login.
They login and on successful login, the pop-up or modal window disappears. (assumes user has registered at a previous point)
The protected content which was hidden or blurred in the main/parent window, appears so the user can proceed to read it.
We can assume that, upon successful login, a cookie (let's say named login-status) is dropped on the user's browser, scoped to .oursite.com which could serve as a flag.
The problem we are facing is that the page in the original window was served over the .google.com domain and therefore we do not expect that it would be possible for the main window to apply display logic on the content based on the cookie named as login-status.
It would appear from this page that the way to solve this challenge is via identifier reconciliation on the server by maintaining a matching table between the reader id that AMP generates and the cookie. We have looked at the AMP access feature and AMP page implementation for New York Times but we cannot tell for sure whether they have achieved this via server side or client side solution.
Can anyone
validate the assumption that it is not possible somehow via AMP to share the login state of a user between 2 windows with content served over different domains?
suggest a way to solve this on the client side rather than the server side?
Thanks in advance
I've been fumbling around with different client side technologies, like AngularJS, EmberJS, even trying to use straight JQuery and figure out how to use ReactJS with it. That aside, my goal is to build a single page app using json in between the client and a Java Jersey 2 jax-rs back end api.
I have two stumbling blocks right now. Some info though..I am deploying my app as a WAR file in Jetty. My back end is java based. I am using only jquery in the client side as of now.
My main stumbling block is how to handle login, logout and session management. With an rest API and using ajax, I have login working, including it setting a cookie. My concern however is with a single page app, there is just the one index page, and if the user closes the browser, then reopens it to the index page while the cookie/session is still good, the user should be logged in, not see the outside (not logged in) page. I am unsure how to handle this, whether it be a jsp page, index.html with some templating library, etc. With JSP I can insert some scriplet code (against my better judgment). In the old days I'd include a header that would check for request.getSession().getAttribute("user") and if it was there..the user was logged in and using scriplet if() code I'd display a logged in header, instead of the non-logged in header. But I am in the belief there has got to be a better way to do this with todays client side JS frameworks.
The other stumbling block is the navigation and dynamic aspects. For example, when I was messing around with angular js, it was easy enough to use Welcome {{name}} and within the scope replace name with a json response value for the logged in user. In my current situation, I am not exactly sure how to best go about displaying dynamic bits like this with pure jquery other than using some sort of $("#elem-id").innerHtml="..." code within the response success method of an ajax call. As well, I am not quite sure how to handle navigation to different pages. My logged in site will have some drop down menus or links that will replace the content area with different varying amounts of content.
So first, what are some ways in a SPA to handle user sessions, in the case of a page reload, or close/crash browser restart.. to ensure the user is still logged in and direct them to the right page? Second, what sort of templating and routing/navigation options exist that don't require me to put a huge ton of code in my one index.jsp page?
Thank you.
If you're having a REST API as the back end, then you must have implemented oAuth as an authentication mechanism. That is, when your user logs in, using a username and a password, you exchange that data with an authentication token. This authentication token is sent your server with each and every API call and your backend validates this token before servicing the request. Clear so far?
What you could do is, when you obtain the access token, you can also obtain the access token expiration time from the server and store that data in your client side app. In localStorage maybe? And when your user closes the browser and reopens again, you can first check whether such access token is available (and not expired) before asking the user to log in. This should solve your first problem.
Secondly, if you're looking for a lightweight routing option, I recommend director.
I am building a similar application. OAuth is not mandatory. You can have normal sessions etc by hitting the jersey login endpoint and setting a session and a cookie "keepme" with the session if user wants to be persistently logged in. You can then have a jersey AuthFilter for example check if either there is a cookie with a valid session or an active session and keep the user logged in.
Your frontend application should have no say over this, just communicate with the server and if it doesn't get unauthorized access (from the AuthFilter) then continues otherwise it displays the login page.
I am writing a Python AppEngine app, and need to deliver notifications to browser clients when certain backend events happen. I am using the channel API. I have two issues: multiple page loads within the same tabs and multiple tabs.
Multiple Page Loads
I seem to be unable to reuse the same channel across multiple page loads. An attempt to reconnect to the channel on the new page results in an error with code 0 and no description. I am currently storing the channel token in the datastore and injecting the token into the page. How can I reuse the same channel for multiple page loads within the same tab? This answer suggests iframes are the way. Is recoding the site with iframe my best option here?
Tabs
My understanding is that I need to generate a client ID for each tab the user opens. How should I generate a client ID that will be different for each opened tab? I could just increment an ID on the server, is that the best way?
Thanks in advance,
Aaron
I have been investigating strange channel disconnections in DEV, and it looks like Channel API is much more stable in the live environment than in the development environment.
I created a (somewhat) minimal AppEngine application that creates a channel that persists across page loads. The app reuses a channel token from the datastore.
The code for the app is here: https://github.com/aaronlifshin/channeltest
The app itself is live at http://channeltestaaron.appspot.com/
How to use it?
When you go to http://channeltestaaron.appspot.com/ANYSTRING the app will create a channel and then reuse this channel for any other URLs you open of the form http://channeltestaaron.appspot.com/ANYTHING
Then you can go to http://channeltestaaron.appspot.com/broadcast to cause a message to be sent to all the other pages you've opened.
All pages have a 1-second delay to test the persistence of the channel. This 1-second delay would cause the channel to disappear in dev.
Hope this is helpful.
Aaron
Multiple page loads: according to the answer here you can reuse the token, however need to make sure to use it on one page at a time (it might also be a good idea to avoid page reloads and to have a single-page app that uses hash fragments).
Tabs: the most straightforward way to generate client ID is create a random string, e.g. like this.
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.
Say, a link to a person is sent to a user via email. If the person is already logged into the webpage in his/her browser, clicking on the link takes him/her to the page. However, if he/she is not logged in, he/she should be asked to login in order to access the page. Is there a way to achieve the above functionality using jquery, javascript?
Yes. Build a back-end authentication system, using AJAX and whatever your server-side language is.
From there, develop a hypermedia-style of content-system, and a modular, "widget"-based application delivery model.
Within your hypermedia responses to login (plus passing whatever relevant path information was gained from the e-mail), either redirect the page to a new page (based on the linked response from the server), or download the widgets requested from the server (for whatever application you're displaying media in), and then stream in AJAX content (again, from a URL dictated by the server-response).
This is about as close as you're going to get to security, in terms of delivering things to the client, in real-time, with authentication.
If you were to load the reports/gallery/game/whatever, and put a div over it, and ask for users to log in, then smart users can just kill the div.
If you include the content, or include the application components (JS files), or even include the links to the JS files which will request and display the content, then clever people are again going to disassemble that, in 20 seconds, flat.
The only way I can see to do this is to have a common request-point, to touch the server, and conditionally load your application, based on "next-steps" URLs, passed to the client, based on successful authorization and/or successfully completing whatever the previous step was, plus doing authentication of some form on each request (REST-based tokens+nonces, or otherwise)...
This would keep the content (and any application-structure which might have vulnerabilities) from the client, until you can guarantee that the client has been properly authorized, and the entire application is running inside of multiple enclosed/sandboxed modules, with no direct access to one another, and only instance-based access to a shared-library.
Is it worth the work?
Who knows.
Are we talking about a NORAD nuclear-launch iPhone app, which must run in JavaScript?
Then no, engineering this whole thing for the next six months isn't overboard.
And again, all of this security falls over as soon as one person leaves themselves logged-in, and leaves their phone on the table (biometric authentication as well, then?).
Are we talking about a gallery or discount-offers that you want to prevent people to log into, so you know that only the invited people are using them?
Well, then an 18-month project to engineer, develop, debug and deploy a system like this is probably going to be overkill.
In this case, perhaps you can just do your best to prevent the average person from stealing your content or using your cut-prices, and accept that people who take the time to dig into and reverse-engineer everything are going to find a way to get what they want, 95 times out of 100.
In that case, perhaps just putting a login div overtop of the page IS what you're going to be looking for...
If you're dealing with, say a company back-end, or with company fiscals or end-user, private-data, or anything of the sort, then aside from meeting legal requirements for collection/display/storage, how much extra work you put into the security of the system depends on how much your company's willing to pay to do it.
If it makes you feel better, there are companies out there that pay $60,000-$150,000 a year, to use JS tracking/testing programs from Adobe. Those programs sit right there, on the webpage, most of the time, for anybody to see, as long as you know where to look.
So this isn't exactly an unknown problem.
Yes it is. By authenticating (login) you can store a "loggedIn" cookie which you have to delete by session end (logout or closing the browser). You can use that cookie to check if somebody is logged in or not. If not logged in, than you can display the login page and send the login request with ajax. Btw it is not a good practice to use hybrid applications like that. It is better to use SPA-s with REST service, or implement this on server side.