There is this site wich in the address bar only shows like "http://example.com/examplepage.aspx".
Normally if it would have parameters behind it you probably could just copy that one.
But since it doesn't, how do i bookmark this page.
It doesn't necessarily have to be a bookmark, but at least an easy way to access the page.
(fyi I know basic HTML and Java, maybe it's only possible programmatically).
thnx
Generally dynamic pages (taking in context with the question) are not book mark friendly.
You could probably sniff the incoming request, and create a fake form which you can then submit later.
However there may be situations where there are parameters such as session id which are valid for only small periods of time.
You should read up on sessions. In really simple terms, a session is assigned to users accessing a website. They have an expiry period. IF you stay idle beyond set time (determined by the developer) you will not be able to get in. And every time you log back in, you may be assign a new session.
You would have noticed, that some websites automatically log you in, this is mostly done with the help of cookies. Cookies work in tandem with sessions, they store very basic information, so the next time you come back to a website, it will be able to identify you as a returning user and provide you with access.
Then again, some pages don't use sessions, they might have their own custom way of identifying users.
Bookmarks can be used in dynamic pages, if the code allows you to send GET requests, if they don't have any other extra parameters which will block you.
To Summarize:
Dynamic page not very bookmark friendly.
There may be parameters used to access a webpage which change constantly, which you cannot really save.
You may be able to get into dynamic pages using bookmarks, if they don't use any of the dynamically changing parameters.
Since you know Java, you should probably read up on JSPs/servlets to get an understanding of what happens behind the scenes in dynamic pages.
Hope this answers your questions.
Related
This question already has answers here:
Design Patterns web based applications [closed]
(5 answers)
Closed 6 years ago.
EDIT: I have posted a somewhat shorter and revised question here: Java web development: transfer control from one servlet to another while passing the request object (Version 2)
As more or less a beginner at Java web development, I’m unsure about how I should structure the flow between servlets/pages when a form is submitted (POST). It’s an elementary issue, I suspect this may be an easy question to answer for the experts. (Still, my book and some googling didn’t deliver a clear answer.) My question is a bit long, and that's because I want to make it clear where I'm coming from. Thanks for you patience.
Let’s say we have two servlets A en B, with each having its ‘own’ .jsp-page; let’s call those pages a.jsp and b.jsp respectively. Now as long as there are no forms on either page (i.e., no POST method used), it’s clear how things should go. That is, before any .jsp-page is shown, the corresponding servlet is activated, doing some preparation for the .jsp-page by setting the relevant data elements (most notably, as attributes of the request object) that the .jsp-page needs, then forwarding the request object (etc.) to the .jsp-page, which then actually displays the page with the data. So for example, a link on page a.jsp may link to the servlet B, and on clicking that link a GET-request for servlet B is triggered, which then does some preparation (setting some request attributes), before forwarding to its ‘own’ .jsp-page (i.e. b.jsp).
But now let’s assume that page a.jsp displays a form with a submit button, method=”POST” and action=”B”. Then yes, servlet B is activated, and this servlet has to determine whether the data entered by the user is valid. If the data is in fact valid, we can simply forward to b.jsp, no problem there. But what if the data is NOT valid?
In that case, we obviously want to show a.jsp (the form page) again, with the data that the user entered the first time still present. One way to achieve this, is to simply have servlet B forward to a.jsp (thus bypassing servlet A). However, there is a big problem with that: the URL shown to the user, in the address bar, will still read “……/B”. So the user will see the correct page (i.e., a.jsp, containing the form), but with the wrong URL (/B). So for example, if we take “Register” and “ThanksForRegistering” instead of “A” and “B”, the user will see register.jsp – but with URL “……/ThanksForRegistering”! Not good.
And calling ‘include()’ instead of ‘forward()’ on the request-dispatcher doesn’t seem to work either. If we do that, not only does it result in a GET-request (as opposed to the POST-request we want), but we actually lose the whole (original) request-object with its attributes (which we need, after all, to re-populate the form). At least, that’s what my own experimentation seems to show. So using ‘include()’ doesn’t seem like a viable option at all.
Another obvious idea is to have "action=A" (instead of "action=B") for the submit. Then the servlet A itself can handle the validation, and if validation fails it can simply forward to a.jsp again, no problem. BUT then what if validation succeeds? Then we want to show the follow-up page b.jsp, but that page may well need the attributes from the original request-object (from the form-submit) again; for example, to have the user check that his entered data was in fact all correct. So basically we have the same problem as before, but with the roles of A and B (and their respective .jsp-pages) reversed. So this doesn't seem like a real solution either.
And I don’t see any other alternatives.
So basically, I’d simply like to be able have one servlet give control back to another servlet, but with the request object being passed from the former to the latter servlet. Or, if that’s not possible, I’d want to be able to forward from servlet B to a.jsp directly, but with the correct URL shown to the user. Or any other way to accomplish what I want.
Many thanks.
I think that the assumption that there has to be one page per servlet is causing the problem here....have one servlet which based on input redirects,forwards or includes a particular page....you dont really need to always invoke a different servlet for a page.....you can have a single front controller with a view resolver the combination of which will redirect or forward to a page.
You can use filters to achieve the same thing or think of setting attributes in HttpSession if validation is successful and retrieve the data in all the pages whenever it is required.
session.setAttribute("object", object);
I hope this is what you are looking for.
I have a list of users across various companies who are using one of the functionality that our website provides. Whenever they contact our business group , we need to send a url via email to the requestor in order for them to upload some data. All these external users do not have any dedicated account. However we do not want a static link to be provided to them as this can be accessed by anyone over the internet. We want dynamic links to be generated. Is this something that is usually done? Is there an industry accepted way of doing this? Should we ensure that the dynamic link expires after a certain amount of time - if so , are there any design options?
Thanks a lot!
Usually, parameters to urls and not the actual urls are what's dynamic. Basically you generate params that are stored somewhere, typically on the database, and send email with the url and the parameter(s). This url is valid for only a limited period of time and possibly only for one request.
Answers to questions:
yes, this is something that is quite commonly used in, for example, unsubscribing from a mailing list or validating an account with a working email address
I'm not aware of any single way that is "industry accepted", there are many ways of doing it, but the idea is not that complex - you just need to decide on a suitable token format
normally you should ensure that the link expires after a certain amount of time. Depending on the use case that can be some days, a week or something else. In practice, you'd remove or disable the generated parameters in your database. However, if this data is something that might be needed for extended periods of time, you might want to think up a functionality so that it can be retrieved later on.
You may have a static URL taking a token as parameter. Eg. http://www.mycompany.com/exchange/<UUID> or http://www.mycompany.com/exchange?token=<UUID>.
The UUID could have a validity in a time range or be limited to a single use (one access or one upload).
Other variant is to use exists cookies on that site in web browser (of course, if they are).
But there are some drawbacks in this solution:
User can open link in different machine, different browser. User can clean all cookies or they can expire after it was visited your site last time when user try to go on granted URL. In these cases user won't access your page.
If user refresh the page continuously using F5 functional key then the page loading is very slow and can be seen blank page for long time.
How to solve this problem?
I tried using cache on server side but I don't think that I am using it in proper way.
Can somebody help me with an example.
I think you need to use browser cache, which can be controlled by http headers, or meta tags.
http://www.mnot.net/cache_docs/
You need to set page cache to be around 5 seconds or some similar value so that no new request will be sent to server in that time interval.
A few things:
You could try to minimize processing time within your application, maybe by minimizing wasteful operations. Sounds like your application spends a lot of time recreating the output.
You could try to add some sort of caching on the server side, and and send the user the same page (ie no "new" processing) for some time. Depending on the mechanism, this may not be feasible though (https, security?). At least, afaik.
Of course you could change the way the site works. You could use Ajax to push information to the site the user is on, and so take the urge to refresh away from him.
And maybe your server just does not have enough power to serve a lot of users at the same time?
It is very difficult to stop user from pressing F5.
Try making your code more optimized.
Use meta tags for cache like:
cache-control
EXPIRES
PRAGMA NO-CACHE
Also check this for JSP caching.
response.setIntHeader("Refresh",5);
just use this jsp method for autorefreeshing of ur webpage...
http://www.tutorialspoint.com/jsp/jsp_auto_refresh.htm
I am interested in creating a simple web application that will take in user input, convert it to an XML file and send the file to a database.
Coding wise I feel I am okay, it is just the general setup and what implementation to use I am a bit unsure of.
At the moment I have a JSP page containing a form, the user fills out the form and on submit a POST method is sent to a servlet, in the servlet doPost() method the servlet is instantiating a java object and passing it the user inputted data. The java object then writes that data to an XML file and sends it to the database via REST.
All I would be interested to know is if this the standard/optimal way of creating such a web application.
Any and all feedback is appreciated.
Thanks
For a "simple webapplication" this high level approach looks fine in general. However, if you want more critical feedback, you'd need to give more details about the low-level approach. It may for example happen that it isn't memory efficient and thus may break when the webapp is been used by over 10 users concurrently, just to give an example.
I only question the choice for the GET method. You'd normally only use it to retrieve data (SELECT), not to create/alter data (INSERT/UPDATE/DELETE). For that you'd normally use POST, so that no one can execute it "accidently" by just clicking a (bookmarked) link. Changing GET to POST isn't that hard, add method="post" to the <form> element and rename doGet() to doPost().
I've already read most of the questions regarding techniques to prevent form spam, but none of them seem to suggest the use of the browser's session.
We have a form that sends an email to given email address and we didn't like the idea of using "captchas" or Javascript, as we wanted to keep the user journey simple and accessible to those without Javascript.
We would like to use the session object to help prevent form spam. Our webapp is developed on Weblogic Server 10 using Struts.
The solution being, when the form loads, it would set a variable in the session object. Once you click submit, we check if the session for the variable. No variable, redirect to the form. Variable exists send the email.
I would really appreciate any opinions/reasons why this might be a bad idea, so we can evaluate this solution against others.
Many thanks,
Jonathan
There is nothing to prevent a spammer from automating the process of downloading your form (thus generating the cookie) and submitting it. It may impose a slight burden on the spammer, but a trivial one.
As an example, a form can be easily downloaded and submitted, with cookies preserved, using a command-line tool such as cURL. This can then be run from a script repeatedly.
Session objects can, depending on implementation, be relatively heavy in terms of resource usage, as well as somewhat slow. Additionally, the spammer, if they realize how you are blocking them, can simply start a new session every time they hit the form by not sending back the session cookie.
So, because that technique relies on the client to behave nicely, and the expected behavior is fairly easy to prevent, it is possibly less useful than some other ways to solve the problem.
Thank you for your reply cdeszaq, but I'm not sure if you mis-understood my question.
For the form submission to complete successfully, clients will be forced to load the form to set up the session object correctly. Only when the session is in the correct state, will it be possible to send an email.
If the spammer is not sending back the session cookie, then they will not be able to spam my form as they haven't gone to my form page that creates the right session.
I agree that using the session object would create extra resource. Our implementation would simply, (using JSP) call session.setAttribute("formLoaded", true); and in my Struts action I would simply use session.getAttribute("formLoaded"); to check.
I wonder if this might work:
Each time you render page/form, create a random bit of text
Put that text in the session
Include that text as a hidden field in the form
User submits the form
Action compares the hidden text to the value in the session - if there's a match, send the email
Since a hacker wouldn't be able to put any random value in the session, they wouldn't be able to spam. Right?