On session timeout we re-direct to the login page and if the user logs back into the portal he gets re-directed to the page he was trying to navigate in the first place.
In our case, the re-directed page tries to fetch values from the session and it fails badly with exceptions and it works just fine when there is no dependency on pages which don't have any dependency on session variables.
What is the best way to handle the situation? Can we just redirect this to the home page instead, if so how to do this?
It depends on how much information you are storing in the session, as a guideline, you should always the "shortest" scope ever.
Probably your best option is to allow redirect only on stateless pages, so that it won't give you any problem about inconsistent state.
As for your last problem, take a look at this: redirecting-on-session-timeout-in-jsf-richfaces-facelet. Just set the tag to whatever you want.
Related
For many applications that I've ever worked on. After logging successfully and session's still active, if users try to access signin/signup page by directly using browser address bar, they'll be redirected to dashboard or home page. I just follows some existing applications such as Goolge perhaps.
But what's the main reason of this flow? Does it raise any security risks if users can still access signin/sigup while their sessions are still active?
The decision to have separate login page or redirection of user to another page depends on the use case or requirement that you have for your website. It is directly related towards the functionality you want to provide to users.
It is mainly for bringing functional separation such that the login page is specifically for logging in and dashboard page or home page is to show the the account details or other related information of your home page. It also can be used for security purpose.
Functionally, having user login and dashboard page on same page can have its own challenges based on the other processing that is being done by you as per your use case. Consider a scenario where an email shall be sent whenever you login and also some additional processing is done based on the login procedure. Each refresh on the posted page would log the user back in. In such a case, every refreshment of the dashboard page would trigger an email and also does additional processing which may not be desired. In the perspective of security, based on your requirement, you may redirect URL based on PRG(Post-Redirect-Get) pattern to a restricted page or guest user page rather than having the main home page when an unauthenticated user logins or based on the subscription type of user.
It should also be noted that having a login mechanism integrated into the main page also has an advantage based on your website requirement as it provides the ability to login without losing the context of what the user is doing which is purely dependent on the requirement for your website. However, a separate login page has the advantage of being easier to implement and also for the pages that have sensitive information, you can simply redirect to the login page, rather than having to worry about rendering UI without the context of a valid session.
This is more of a usability feature than a security one. Developers put a bit of additional effort to implement stuff like this. Here is an example how they do it.
You should probably look into "OAUTH2" or similar authorization (beware not authentication) software, that might spread the light its about tokens and who might use them where and when. (pretty shady that's why im gonna leave that link here but you should really dig deeper for yourself)
https://docs.apigee.com/api-platform/system-administration/using-oauth2
Fairly new to capybara and cucumber (and testing in general) here.
I am doing some black box acceptance testing and I need to test a page that can only be reached by typing in the url.
That page requires authentication so when the page is reached through a call to visit() I am redirected to the login page.
The problem is after logging in the app does not redirect me back to that page but goes to the homepage instead so I can't just fill in the login form and move on.
I have tried logging in first and then performing a call to that page but it seems the session is cleared after any call to visit().
How can I keep the session after a call to visit, or solve this problem in any other way?
Ideally I would like to log in once and visit a bunch of pages only reachable by typing the uri, without having to log in again and again. Is that possible?
I am only using the chrome selenium driver but at some point will use a headless driver.
Thanks!
As the answer by #diabolist correctly states, visit doesn't reset any session (as long as your log in actions wait long enough for the log in to actually occur and the cookies to be set (expectation on a message stating you're logged in, or have_current_path(root_path) etc). Rather the session gets reset between scenarios.
If, in one scenario, you are logging in and then finding that you're not logged in when you visit a page you expected to be logged in to then it's possible you're actually logging into the wrong domain. By default Capybara will visit a path on the host 127.0.0.1 - If that is where you're visiting but your app is redirecting to localhost (or www.example.com, etc) for logging in, then the session cookies will get set on the wrong domain and when you visit a page back on 127.0.0.1 you won't be logged in. If that is the case then you can either change Capybara.server_host or fix your app so it redirects to the correct place in the test environment.
Given I am registered
And I am logged in
When I visit the test page
...
These can be implemented as
Given "I am registered" do
# do whatever it takes to be registered
end
Given "I am logged in"
#visit log in form and fill in id|password
end
When "I visit the test page" do
visit test_page_url
end
Your idea that your session is cleared after each call to visit is wrong. Each scenario has its own session, and you can perform multiple visits in a scenario. However you have to make sure you login (and register) in one single scenario
We're using JSF in a very simple way. All we're doing is implementing tags that contain a little Java code.
I have implemented a "security" tag that sends a 302 redirect back to the login page whenever the user isn't logged in:
// make them log in
ctx.getExternalContext().redirect("login.xhtml");
ctx.responseComplete();
The trouble is that the redirect() method doesn't stop the rest of the page being rendered. Tags that are further down the page are getting executed. This is a problem because non-logged-in users could see things they shouldn't if they had their browser ignore redirects.
How do I get responseComplete() to do what I thought it was supposed to do?
Its always better to implement the login related logic in a servlet filter, like below:
Implement a filter for the URL patterns that you want to secure
In the filter, check if the user is logged in (may be by just checking if Username/UserId is present in user session)
If the user is not logged in, redirect the user to a HTML based login page.
If the user is logged in, let the user access the resources.
There are a lot of ways (may be better than this) to implement this, but this is the most basic one.
Maybe you could use a flag to verify if the user is logged in.
Then, you can use the render=#{managedBean.logged} property in the tags you don't want to render.
This is just a workaround... can't really help too much with that amount of information you gave.
Try it!
ctx.getExternalContext().dispatch("login.xhtml");
ctx.responseComplete();
I'm working on a really simple web site. I usually do a full blown admin to edit the site, but this time I thought about editing in place (contenteditable="true").
To simplify login for the user, I'd like to just give him a password that he can type in the address bar to log him in, instead of the usual login form. So he would visit domain.com/page?p=the_password and then I would store his data in a session and give him a cookie with a session id (usual stuff) and redirect him to domain.com/page.
How safe / unsafe is this? I'm doing this in PHP, but I guess it applies to any server-side language.
Your login idea is unsafe: URLs for requests end up in web server logs and other places besides, so that means passwords will end up in web server logs.
Your "contentedittable" idea is probably unsafe, but in a more subtle way. It's also (again, probably) non-compliant with the HTTP specification.
GET requests should always be idempotent. This is because user agents (browsers, caches, etc...) are allowed to reissue the same GET request any number of times without user consent. One reason why a browser might do that is because the user pressed the back button and the previous page is no longer in the cache. If the request is not idempotent then issuing it a second time may have an unexpected and unwanted side effect.
It sounds like your "editing in place" feature might not always be idempotent. There are many kinds of simple edits which are in fact idempotent so I could be wrong, but as soon as you have for example the ability to add a new item to a list via this kind of interface it's not.
Non-idempotent requests should be issued through methods like PUT, POST, and DELETE.
To add to #Celada answer. The URL will be stored in the browser history or network caches/proxies, so the password can leak in this way. Also it would be trivial to login a random Internet user as someone else (Login Cross Site Request Forgery attack), by for example having a web site with an img element pointing to domain.com/page?p=the_password
You don't write about this, but once the user is logged in your scheme needs to protect against Cross Site Request Forgery (so a random page can not perform admin actions on behave of the logged-in user).
I initially designed my site to show a login box at the top of the page if the user was not authenticated (e.g. how reddit.com works).
I encountered a user who was having trouble with their browser's storage of their password because after a password change because their browser had stored their login information at different urls on the website. Even after the user typed correctly the new login information at one url, and the browser updated it, there would be other urls at which the browser had the incorrect login information.
This would also cause problems with sites that have a login box on their main page, and a special login page -- especially if the user front page login box is sent to the login page.
Is this a small enough case not to bother with, or should there only be one url at which a user can login to prevent this problem, especially for less technically-savvy audiences?
There should be one login page that every other page accessible sans login links to. It standardizes the process of logging in and reduces the kind of confusion your user experienced. It conforms to a convention that all the browsers are using with respect to saving passwords as well. Don't really see how you can go wrong that way.
Most sites use a single "sign in" button that takes you to the canonical login page.
If you want a signin box on every page that the browser can remember, consider using an iframe to hold the form.
I believe that if there is any way to use only ONE login location you should try to do it that way.
As you yourself said it's quite hard for browsers to determine what to do with stored passwords for sites with multiple login locations. There are possibly other problems and all of them are solved by having exactly one login location.
If you need to provide login from more places, just use redirection. But getting "in" your system should be done from one single place.
Just have one login page and have the other pages on your site linking to it. It keeps it simple for end users as there is only one page and easy for you to manage as you one have one login page.