The GWT History: com.google.gwt.user.client.History has a back() method which takes you to previous history token. But is there a way to get value of previous history token? Or even 2 steps previous history token?
I checked the back() method implementation for some quick leads, but that's all JS native stuff!
Using the History class? No. Javascript doesn't expose this information for security reasons. You shouldn't be able to spy on a user's browser history. That said, you could employ history sniffing tricks and do it, but those are all hacks of one form or another and, to my knowledge, are not very accurate.
Your best bet would be to keep track of the history state manually. Maintain a stack of visited states and with every token change "push" and with the back button "pop". Then you can see where you were previously and even further.
If you are going beyond just changing tokens and are changing pages within your site/application, consider sticking that stack of pages into LocalStorage. With this approach, you could even keep track of the history between refreshes and visits.
I just came to the same question, but the answer is actually different: you can get notified of the history entries by registring
a change handler
as mentioned in the official doc
Related
I am trying to figure out how to run an A/B Test for a change on a Page Step for a Single Page. The idea is we have a payment flow with several page steps each containing a form. We'd like to swap out forms and test how our users react. We are trying to avoid changing the URL.
I looked into tools such as Google Analytics, but that requires a different URL to run the A/B test. The hesitation about creating a new URL is because our users are known to bookmark them, and we don't want to keep a backlog of redirects from invalid URLs, also we'd like to avoid constantly deploying new URLs for our tests.
I cannot seem to find any tool to do this, so I've tried to think of a few solutions but I'm not having a lot of luck.
My best idea is to build both a and b forms into the page, and when a user accesses the flow, the session randomly(based on a preset%) stores a value that dictates whether the user is in test a or b. Then when they step into that form, the server will serve the proper form to them. If they abandon their session, we'd track that, and if they complete the action, we'd track that.
I feel like there should be a better solution, but I just cannot come up with one.
My results online were either blogs showing how to approach it from a high level, and all of them used different URLs, I have found almost no developer resources.
Thanks.
We're using ExtJS 4.2.2, and .NET as our server.
Whenever you need the server to be involved, you need server-side instrumentation. No free tools offer that, but you could consider Optimizely "full-stack" (has support for C#) or Variant (does not yet).
I am new ta GWT and I would like to know if there is a way to handler browser refresh. What happens now is that each time a user refreshes the page, or click F5, the application returns the user to the login page. what I want is to have the user stay at the same page when the page is refreshed. An example would be perfect.
Thanks a lot in advance!
Take a look at the Activities and Places design pattern for GWT.
It is a highly recommended approach that can handle page refreshes as well as back and forward buttons, and allows users to bookmark "pages" within your app.
Along with looking at activities and places which is a very useful way of handling navigation in an ajax application you will also need to handle the session from the server. You would have a call to do authentication either through a realm or some kind of homegrown authentication. I recommend Apache Shiro if you are just getting started. When you application loads from a refresh you need to make a call to the server to validate that the session you have is still valid and if so, you would send the user to the correct Place/Activity. The Activity/Places is a little bit more boiler plate but it is worth it in the long run and makes the application much more flexible. You may also want to checkout Arcbees GWTP plugin. This will handle most of the boilerplate for you but beware it can be a little complex to a newby. It uses Gin for dependecy injection and has some custom place mapping things that are a little different. But overall the documentation is very good and the gwtp eclipse plugin can save you some copying and pasting for some things.
You should look at the GWTP car store example. They did what you are looking for. https://github.com/ArcBees/GWTP/tree/master/gwtp-carstore
I would recommend you to consider History Tokens in your development to handle adhoc F5 refresh problems. Please have a look at http://www.gwtproject.org/doc/latest/DevGuideCodingBasicsHistory.html. While changing from one screen/layout to other, History Tokens help your browser keep track of the changes, because History Tokens change the URL itself. Examples can be found in the shared link.
I had an idea about website vulnerabilities, and I would like to know if it is possible. Also some suggestions on how to fix them.
If some part of my website writes data to the DOM and then calls the data back from it, would it be possible for someone to “hack” the server by editing the DOM in the browser?
For example, suppose I have some radio buttons. Each button has its own logic associated with it. If I remove one of the buttons, but fail to remove or comment out the logic, could someone go in and edit the DOM name of one of the buttons to the removed one, and upon submission have the server execute the logic associated with the removed radio button?
I understand how to fix that situation, by removing or commenting out the removed button’s logic, but I fear my site relies too heavily on such things that could be manipulated via the DOM. Hence, I’m wondering:
Is such a thing possible?
Is some complex validation method the only way to prevent “hacks” of this nature?
The answer to your question is yes. For example in many browsers you can open a javascript console and change not only the DOM but also the javascript on the site.
There is no guarantee that the code you write for a webpage will be run as you code it. Any user can change their copy. What they should not be able to do is change other people's copy. When they do this is called a cross site scripting (XSS) attack. (Typically done by adding script to a field which is saved in a database server and then served to another user.)
To protect your site you need to ensure that all web service calls are secure -- that is a user can't call them with malicious data and cause problems.
You also need to block against SQL injection attacks.
There is NO way to protect against a user changing the web page on their machine and having it do something you did not intend, so all validation needs to occur both in the browser and on the server.
As an example of how easy it is to change the local browser behavior, consider the browser extension. A browser extension is a pre-coded way to change the way web pages act locally.
(Think about ad-blockers as a specific example.)
I wan to make some fixed divs on bottom persistent without reloading them if user is on my site. It is like Facebook chat, user can be all over the site but chat is allways visible?
This queston is because I have created chat with NodeJS and when page is refreshed connection is destroyed and again created, so I want to make this connection persistent even during the reloading the page.
I know possible soluton that make every request Ajax call, but... this is unusable....
You can try localstorage. Data will persist on reload.
Use that with json.stringify and json.parse to make it work.
Unfortunately some older browsers still in use won't like that. I think all new browser versions can use localstorage. If you're not concerned about old browsers that's fine too.
There are localstorage shims, but that depends on how much work you're willing to put in to your project.
You can use localstorage to just store the html too if you like.
I prefer dom element updates using json values myself.
Visit browser version market share and you'll see quite a few of the older versions are out of usage. Though like with any tech usage stats you should take them with a grain of salt.
Edit Whoops! You said fixed divs without reloading them. I don't think that's possible if they are a chat. Unless I don't understand the question. Post some code if you can.
Im working on a web service that i want to be RESTful. I know about the CRUD way of doing things, but I have a few things that im not completly clear with. So this is the case:
I have a tracking service that collects some data in the browser (client) and then sends it off to the tracking server. There are 2 cases, one where the profile exists and one where it does not. Finally the service returns some elements that has to be injected to the DOM.
So basically i need 2 web services:
http://mydomain.tld/profiles/
http://mydomain.tld/elements/
Question 1:
Right now im only using GET, but im rewriting the server to support CRUD. So in that case i have to use POST if the profile does not exist. Something like http://mydomain.tld/profiles/ and then POST payload have the information to save. If the profile is existing i use PUT and http://mydomain.tld/profiles// and payload of PUT has data to save. All good, but problem is that as far as i understand, xmlhttp does not support PUT. Now is it ok to use POST even though its an update?
Question 2:
As said my service returns some elements to be injected into the DOM, when a track is made. Logically, to keep it RESTful, i guess that i would have to use POST/PUT to update the profile and then GET to get the elements to inject. But to save bandwidth and resources on the serverside, it makes more sense to return the elements with the POST/PUT to profiles, even though its a different resource. What are your take on this?
BR/Sune
EDIT:
Question 3:
In some cases i only want to update the profile and NOT receive back elements. Could i still use same resource and then using a payload parameter to specify if i want elements, e.g. "dont_receive_elements:true"
On question #1, are you sure that xmlhttp does not support "put"? I just ran http://www.mnot.net/javascript/xmlhttprequest/ on three browsers (Chrome, Firefox, IE) and according to the output, "put" was successful on all browsers. Following the information on http://www.slideshare.net/apigee/rest-design-webinar (and I highly recommend checking out the many Apigee videos and slideshows on restful API), "put" is recommended for the use case you mention.
But you may be able to avoid this issue entirely by thinking a little differently about your data. Is it possible to consider that you have a profile and that for each profile you have 0 or more sets of payload information? In this model the two cases are:
1. No profile exists, create profile with a POST on .../profiles/ Then add elements/tracking data with posts to .../profile/123/tracks/ (or .../profile/123/elements/)
2. Profile exists, just add the elements/tracking data
(Sorry without understanding your model in detail, it is hard to be very precise).
As for question #2 - going with a data model where a profile has 0 or more elements, you could update the profile (adding the necessary elements) and then return the updated profile (and its full graph of elements), saving you any additional gets.
More generally on question #2, as the developer of the API you have a fair amount of freedom in the REST world - if you are focused on making it easy and obvious for the consumers of your API then you are probably fine.
Bottom line: Check out www.apigee.com - they know much more than I.
#Richard - thanks alot for your links and feedback. The solution i came down to is to make the API simple and clean as you suggest in your comment, having seperate calls to each resouce.
Then to be able to save bandwidth and keep performance up, I made a "non-official" function in the API that works like a proxy internally and are called with a single GET, that updates a profile and returns an element. This, i know, is not very restful etc, but it handles my situation and is not part of the official API. The reason i need it to support GET for this i need to call it from javascript and cross domain.
I guess i could have solved the cross domain by using JSONP, but i would still have to make the API "unclean" :)