Suppose I am going to create a web page with two box, for entering the user id and user password respectively. And then once i click the submit button, it will check with the database in background whether this user exist. If it matches anyone in the database, the user id and user password will be forwarded to the other page, at the same time it will redirect to that user's main page.
Can I just use servlet to complete this task?
I found there is request.Dispatcher API but is it enough for the task?
String name = "Tom"
request.setAttribute("name",name);
RequestDispatcher dis = request.getRequestDispatcher
("Servlet2");
request.Forward(request,response);
in second servlet file
request.getAttribute("name");
//this line will display "Tom"
One more question to ask, how about clicking a link (INSTEAD OF BUTTON) to pass some data and redirect to other servlet pages? Any idea? Many thanks for your reply.
Yes, you can use a servlet for this. Whether the dispatcher is enough or not depends on the concrete functional requirements which are not fully clear from your question. The canonical approach, however, is to store the logged-in user in the session scope instead of in the request scope. Otherwise the user has to login everytime the user want to visit a restricted page.
Also, you normally would like to send a redirect after the login succeeds. This way the new URL get reflected in browser's address bar. Also this way pressing F5 afterwards won't cause any possible surprises. Forwarding from one to another servlet is at its own also somewhat a design smell. Including would have been reasonable, but forwarding not. As said, send a redirect instead.
As to using a link to submit a form, just execute JS form.submit() during the click event.
<form id="login">
...
login
</form>
An alternative is to style the button to look like a link with a little help of CSS. This way it'll also work on clients who have JS disabled (for example, the handheld users).
Related
I am trying to configure an action in the ontology manager application. This action edits objects that are currently used in production, so we need to make sure that users to not accidentally submit actions. As such, I would like to configure an extra pop up that will ask the user for explicit confirmation before the action submission goes through. Is this possible? Ideally it would look something like the confirmation popup that is shown by Foundry when you try to delete a dataset (see screenshot below).
Within the action form you could add another parameter asking the user to confirm with a specific word (e.g. 'I Acknowledge') that they really want to make those changes. I drafted this up in a Workshop app.
My name is Alex.
Sorry for my rather bad Englisch because i come from Germany.
I just started programming with Node.js.
Previously i made some small static HTML and CSS websites.
I have some beginner questions (which might be dump).
I think these questions are very general for now and have therefore not included any code examples.
So far I have written a static HTML website which I host locally on my computer using Node.js and Express.
My Questions are:
Which actions within a web application should take place on the client side and which on the server side. For example, I have several buttons on the start page. With the help of which predefined users can log in. When clicking on a button, the user should be redirected to the login page. The user name of the respective user should be entered directly into the username field on the login page.
How do I implement such a transition?
The username would probably have to be passed to the server using a post call. How does the user get to the next page? Should this be a simple link or should I send the new HTML document to the user via app.sendFile()?
For example, how do I change tags in an HTML document using Node.js. The same example as before a user is logged in and redirected to the next page. Now he should be greeted with his name. The name can be read from a database using the UUID.
How do I get this name into a tag?
Do I need a template engine or are there other ways to change a static HTML page.
Thank you in advance for your help.
In my opinion, security-critical parts logic be placed on the server (logging in, checking balance, authorization, etc.).
Traditionally, no code on the client side is required. You click a link/submit a form, which sends a request to a server, the server responds, the client displays the new page.
Using client side code, however, can make your app smoother and reduce the load of the server. For example: the user clicks on the shopping cart button. Instead of reloading the whole page, the user sends an ajax request, and the server responds with the cart data. Then the client updates the document, displaying the formatted cart data.
You can't "change html tags" from nodejs. You can send a response. If you send a html response, you decide how to produce the response. You can just concatenate html strings, but using a template engine is a better solution.
We are creating a Gmail add-on that integrates with a CRM product. The product is single-tenant and every client has their own site path under our domain. Each client also has their own path to authorize with, e.g. https://example.com/siteA/oauth/authorize.
When setting up the custom auth screens, it looks like we are expected to know the url to assign to a click event on the auth button.
authButton2 = CardService.newTextButton().setText('Begin Authorization!')
.setAuthorizationAction(CardService.newAuthorizationAction()
.setAuthorizationUrl(authurl));
I would like to have some user input before this point. I was playing with an input field where the user could type their site name an then click the authorize button although I was not able to overwrite the original authurl supplied to the setAuthorizationUrl method.
Ideally it would be nice if the add-ons had a way to store some one-time input (like "site name" in this example) so we would not have to ask again, but I have not found anything like this.
This seems like we need a central auth endpoint but am trying to avoid this.
Anyone have any experience with this or any ideas?
Just build the authorization button using the proper url after you get it from the user input.
You can't modify that button once you create it. Rather than modify it, just create the button after you receive the url and reload that card. Or put the authorization button a new card that you push to the top once you receive user input on the auth url.
How can we submit a form without Javascript and not by pressing any buttons?
I need to transfer a content to another file when a function works under certain conditions. Both the files are written in Perl. The pages are loaded in a webserver(same). I need to transfer a value, which the user doesn't want to know what I'm sending. So I came up with the post method is safe.
But there I didn't find any ways to redirect a URL where the values are transmitted in post method. So I came up with the form submission. But the problem is I need to use javascript or make user to press a button to complete the task.
The problem with Js is there some users who disable JS in their browsers.
So using it is not preferable. With the button,
I can't make the user to do that for me.
Is there any other scripting language, which supports such functionality?
There are some conditions that I can't use session
What I did is encryption for identifying the user from knowing what data is transmitted. The receiving page will decrypt it when it is required. But it's not what I needed.
I need to transfer a value, which the user doesn't want to know what I'm sending. So I came up with the post method is safe.
It isn't. If you pass it through the user's browser, then the user can see it.
Is there any other scripting language, which supports such functionality?
No. There is no programming language as well supported in browsers as JavaScript, and none that are harder to disable then JS.
Store the value on the server (you could use a session) and redirect the user with a normal 302 status and Location header. You can pass a session token via cookies or the query string.
You can't make a user do anything, unless you're writing for a browser the equivalent of a trojan.
But secondly, without something on the client side, you can't ensure that you can get information that you didn't have when you sent the page.
You could place some links, and know which links they clicked on by passing it through a central tracking program, but those links wouldn't have anything in them that didn't originate on the server without client script running.
Still, despite that you can entice a user to click on a link more than a simply functional button, in either case you can't get guaranteed new information from them. They can always close the tab, close the browser, or press the back button. This goes back to point #1: you can't make users do anything.
I'm building a site that offers functionality to users without requiring them to register. The idea is to send an email to the specified address containing a link with a token. That way the user would could this link anytime they want to make changes to the functionality.
While I realize that there is no way to truly secure such a concept, I'm looking for options to minimize the visibility of the token. In its current state, soon as the user clicks on the link it is added to their browser history, available to anyone who has access to the computer.
In most cases I would over come this with a simple form so that the token could be passed through with a POST request, but forms aren't really supported in emails.
So the question is, does anyone know of an alternative way to hide a token in such an email?
I'm sure you've thought of this, but you could send them a password and a link to a URL where they'd need to enter that password. If the emailed URL contained another password, it would be a smaller compromise to security than usual to make the user-entered password quite short, like a PIN number, say.
You could resend a new token every time the user wants to log in. Have them plop in their email address and send them a new token, while setting previous tokens to 'expired.' Or, if the server detects that an old link/token was used, it could automatically send a new one to the associated email address and ask the user to check their email for a new link.
That would require keeping track of old, expired tokens and the associated email addresses, but still requires no registration - just that a user check their mail every time they want to log in. You'd essentially be piggy backing on their email authentication.
It'd also be counter-intuitive for users.
This would turn the token into a cryptographic nonce, which is primarily used to prevent the replay attack you mentioned.
Another answer, perhaps more useful:
Some browsers (like Chrome) do not record 301 "Moved Permanently" redirects in the browser history. Firefox does, but there's a proposal to change that:
https://wiki.mozilla.org/Browser_History:Redirects
For example, in Chrome, if you navigate directly to
amazon.com
it will follow a 301 Redirect to
www.amazon.com
If you then check your browser history, it will only show
www.amazon.com
Thus, if your server returns a 301 redirect from the login link, the server could record the token, remove it from the redirect link, and the user's browser would only record the redirect link.
(this is my first time responding on stack overflow - let me know if my writing is unclear or if I'm missing other etiquette)