It is a well known problem to every web developer. As far as I tried to find a good solution to this problem - there was none (or at least I could not find it).
Lets assume the following:
The user does not behave, as he was expected to. The actual project I'm working in uses a navigation within the web portal. But if the user uses the browser's back button, the whole thing becomes jeoprady[?] and the result was not always predictable.
We used the struts framework and stored the back-url into forms - at some places, where we needed a back-url - this has been rendered out of this form's back-url. For there was only a singe field for this information and therefore it was not possible of going back multiple steps.
When you change the "struts-flow" - which may result in using a different form - this information will be lost.
If the user dares to put a bookmark somewhere within your webapp - this information may never have been set and again the result will again be either unpredictable or not flexible enough!
My "solution":
I was storing every navigation-relevant page the user visited onto a stack-like storage into the session. This means a navigation-path is collected and stored for later navigations.
At any page within the webapp, where back-navigations are involved I used a self-made tag which renders the stack-content into the url.
And thats it.
When this back-url was clicked, the stack has been filled with the content from the back-url clicked by the user (which holds all information from the stack once the back-link was rendered).
This is quite clear, because a click on a link is a clear state, where the web developer exactly knows, where the user "is" a this very moment - absolutely independant from whatever the user did before (e.g. hitting the browser back button multiple times). Then the navigation stack is built upon this new state.
Resumé:
It becomes clear, that this won't be the best solution. But it allows storing additional information on the stack like page parameters and some other useful stuff (further developments possible).
So, what were your solutions to this problem?
cheers,
mana
The stack solution sounds interesting, but it will probably break if the user chooses to navigate "in parallel" on different tabs or using bookmarks.
I'm afraid I don't really understand why you have to keep all this state for each user: ideally the web should follow the REST principle and be completely stateless. Therefore a single URL should identify a single resource, without having to keep the navigation history of each user.
If your web app relies heavily on AJAX, you could try to implement something like GMail (admittedly, not so easy...), where each change in the interface is reflected in a change in the page URL. Therefore each page is identified by the current URL and the user can navigate concurrently or use the back button as usual.
Related
Does IBM Domino track the last login date for web users(UserName/Password and internet certificate)? I know the access logs contains this information but wanted to know if there may be something built into Domino (maybe in Address Book). Trying to come up with a method to disable web accounts that have not accessed a domino server in a specified time period.
Thanks,
Kev
The User Activity area in the Database Properties picks up from the log.nsf, which is where this information is stored. But, typically, the log.nsf will only have a few days' worth of information. When I've had this requirement before, I've manually captured it via a custom login page or an initUser function I've had in applications.
One of the easiest solutions is to trigger an action from a live web page that generates a database.nsf?openagent event.
like:
or
Ideally you've use the openagent to print a content type and a response, but if you don't browsers do pretty well with invalid responses from servers.
inside your "myagent" you will have the users name available to you to write it to a document.
Your next challenge will be in getting the agent to trigger, but, not too often, ideally only on login.
When a user uses a custom login form it submits the username/password and redirection url in POST method. You could change that to ...?openagent&nexturl=/blablabla.nsf
Your tiny little agent would run one and only one time upon login and update a document in a your custom logging database.
That's a developer's solution.
There are also admin solutions. The server does keep track of active web sessions, but, it does not drop them into the log.nsf like it does upon session ending for a notes session. I don't think it would be too much work from an admin standpoint to get that information there are a lot of event triggers available to you. It's just been way too long since I worked on any server that anyone cared about statistics.
before write the question sorry for my english. My question is this:
I have an web application in jsf, the application have new, edit and delete Categories, outgoings, Budgets, users, etc.
When open the edit page i have the url like this:
http://localhost:8080/Practica3/faces/usuarios/edit.xhtml?id=2
the problem is if the user change the number 2 for another number, and the another number exists in the dababase, the page change the data of the id 2 to the data of the new id.
The problem is if the id number X is of a data of another user, and the user that change the id is not in conditions to see that data.
How disable the edit of the id, or denied to show the data to the another user?
Thanks, and i hope have a response.
Just check in service layer if the current user is allowed to edit the requested entity. If not, then throw some security exception for which you could if necessary configure a custom error page in web.xml.
The technical problem has nothing to do with HTTP/JSF. If you "fix" it alone in JSF side, then you still have a gaping security hole in service layer which would affect any other frontend using it. The frontend is not responsible for business restrictions in service layer itself.
The problem is not stopping the editing of the ID. That is on the client side/browser and you cannot stop this value from being edited.
You need to implement propery Access Security Controls. When you get any response back, you need to check if the user can perform the action they specified (read, update, delete, etc.) as well as checking to make sure they have permission to the data they want to perform the action on.
These two topics are on the OWASP Top 10:
A4-Insecure Direct Object References
A7-Missing Function Level Access Control
The pages will tell you what the problem is, mitigation stragegies, and different ways of testing for that in your application.
I would also become familiar with the other Top 10 categories (this is not an all inclusive list but a good starting point).
When should I have addresses with # and when should I have separate address for each page or part of a page.
For example
https://ca.news.yahoo.com/nick-hornby-boys-read-telling-101350029.html
I know sometimes we need to have #, for instance when we call a javascript method to show a lightbox(modal) but some websites are using it in their unique address of their pages.
For example icloud is using it to show its modal when you click on create one now link.
https://www.icloud.com/#
However, as I said some websites are using that as a method to have unique addresses for their pages.
For example following address that is showing a single page of icloud website.
https://www.icloud.com/#find
Is that correct to follow this practice of having # in our unique address of the website pages similar to what icloud website has?
I am not asking about icloud.com thats just an example. What I meant is that if you go to www.icloud.com/#find page you would see it is not a single page website because there is just a header, login page and a footer. So why they are using #find and not something like find.html? Is there any specific reason that I am missing?
URL fragments(#whatever) are a way to address sup-parts of a document. You should keep in mind that these are never sent to or seen by the server so you can't really use them serverside to differentiate between URLs. You can use them to make parts of a static page addressable or, with the right amount of JS contortions, use them as a foundation for addressable navigation within a single page app. Some JS frameworks rely on this fairly explicitly although with is starting to go out of style as most browsers now support the history api.
I have just set up and created by first ever SharePoint development effort: a project for a web part, to be hosted in a SharePoint Online instance (my Office 365 trial).
I have figured out how to use the List API to pull the content I am supposed to present, being a rotating list of banner images, but I have one remaining concern. I would like to keep track of where in the list I am, and when last I changed images. Another question of mine answers this quite nicely if I go with local storage, but is there any SharePoint REST or JSOM API I can use to persist this state in the SharePoint service?
I like the local storage answer, but you could also write the state information to another SharePoint list.
Keep track of the information on a per user basis (probably against their user ID, since they'll likely be authenticated) and have send an AJAX request or a JSOM request without any visible callback behavior each time the viewer's state changes (maybe even use a web worker for users that support them).
Writing info to SharePoint lists isn't the fastest operation in the world, so it's possible you could have the banner rotate, the request fire, and the user close the browser before the request was complete -- but in that case they would just wind up on the same slide they were at before (so just repeating the last step in the rare occassion where this happens).
On websites like eBay, if you would time-out of your session, and say you were looking at a shoe, when you come back(after your sleep) to the page, you'd see the shoe, but you're logged out.
However, once you log back in, you get directed to that shoe immediately.
I am thinking that I say : "After timeout from website, upon re-login go back directly to page where timeout happened."
But how is this functionality described(as in, what technologies will we use)? Also, is it something that needs alot of resources?
Quite often it's done by having a "Return To" url passed along to the login page.
So.... (Logged in)
Visit Shoe Page
Session Times out
Either via js on timeout or next page refresh, user will see logged-out shoe page
Login link on that page includes the url of the shoe page eg Login.php?ReturnTo=ShoePage.php
Note that this applies to websites. You've also added a web service tag which is completely different - web services have no concept of a "current page"
If you decide to store the last page for the user in the db, what happens if the last page visited is no longer valid? You'd also be adding 1 Db operation per page load (to update the last visited page). No real performance concern but worth knowing. It's slightly non-standard behavior so you'd need to make sure the user knows why they've been redirected