After logout I need to invalidate session and start a new immediately. I used the function
VaadinSession.getCurrent().getSession().invalidate();
After several seconds a red box "Session expired" appears. User must click on it or press F5. How to avoid it and to display new session page immediately?
In javascript is it easy:
document.location='/';
How to do the same in Vaadin? The behavior should be the same as by first visit the page after restarting explorer.
In my project I use this:
Page.getCurrent().setLocation( "/" );
VaadinSession.getCurrent().close();
Related
I wrote a cypress script to log in to the application ( enter the user id, password and click the log-in button), and expecting to load the home page. Cypress enters the user id, password and clicks the button but, loads the login page again instead of the home page.
Below is my script to login:
`
cy.visit('https://digitalxq1.com/sis/basic?accountNumber=123456');
cy.enterText(txtUserID, userid);
cy.enterText(txtPwd, 121212);
cy.clickElement(btnPwd);
Has anyone faced a similar issue? And, Does anyone knows the solution? Please assist.
The nature of the application forced me to log in first without account no- " cy.visit('https://digitalxq1.com/sis/basic'" and reload the app with account number after that - "cy.visit('https://digitalxq1.com/sis/basic?accountNumber=123456')" ).
I made mistake of doing the refresh immediately after clicking on login button as below:
cy.visit('https://digitalxq1.com/sis/basic');
cy.enterText(txtUserID, userid);
cy.enterText(txtPwd, 121212);
cy.clickElement(btnPwd);
cy.visit('https://digitalxq1.com/sis/basic?accountNumber=123456'
Somehow cypress unable to respond to the refresh and loaded the login page again. As a solution, I did validate whether the app is loaded or not after clicking login button. Then proceeded with refresh as below:
cy.visit('https://digitalxq1.com/sis/basic');
cy.enterText(txtUserID, userid);
cy.enterText(txtPwd, 121212);
cy.clickElement(btnPwd);
cy.get(#testElement). should('have.length',2);
cy.visit('https://digitalxq1.com/sis/basic?accountNumber=123456'
This approach resolved my issue.
Try this cy.reload(); this will work.
If you want to reload the page with cache then try this cy.reload(true)
I'm experiencing a strange problem with the Edge-Browser.
I'm using an ajax-call to login a user. As long as the user is in the same window, the session vars seem to be persistent.
But as soon as I open a new window (target="_blank") the session vars seem to be lost and the user isn't logged in anymore. The session vars are gone in the opening window as well.
I'm using this to set and get the session vars:
$sessionData = $GLOBALS['TSFE']->fe_user->getKey('ses', self::$prefixKey . $key);
$GLOBALS['TSFE']->fe_user->setKey('ses', self::$prefixKey . $key, $sessionData);
$GLOBALS['TSFE']->fe_user->storeSessionData();
It's happening in all versions of Edge - interestingly, for once it doesn't happen in IE.
Any ideas?
[Edit for clarification]: The new window is on the same domain as the opening one. No subdomains, no nothing.
Which version of Edge browser are you using? Please refer to the following steps to make sure you are not disabled cookies in Edge browser:
Open Edge browser, click on the More actions button in the top right
corner and select Settings.
Click View Advanced Settings. You’ll need to scroll down to the
bottom of the page.
Press the dropdown arrow under the Cookies field.
Select Don't block cookies.
If still not working, try to reset the Edge browser setting.
I am working in a website like https://jira.atlassian.com/ using firefox, after clicking the "log in" on the top right corner, i am taken to the next login page, where on the right of "log in" button, there is this "stay logged in" checkbox, already checked.
I tested it manually. It seems that after i log in successfully, if i do not exit the page by log out, but simply close the page, the next time i enter https://jira.atlassian.com/, i am already logged in. Ok, make sense.
However, if testing such using selenium webdriver, log in, close page, open page again, the above does not happen.
My question is what is the mechanism for this "stay logged in", is it the same as "remember me"? and how do i make it happen when using selenium webdriver?
Up till now my understanding is:
this happens because of cookie
cookie is stored in firefox profile
selenium start with a default profile that does not include cookie, and can not store cookie during the test
Is there a relatively standard solution for this problem, in java preferably?
Thanks,
As far as I am aware, each instance of loading a FF with Selenium opens a stripped browser with no history/cookies/extensions etc. It's as if you have just download FF for the first time and its a fresh copy. I am not sure how to solve this issue. Maybe if you keep the session open by not closing the browser down but log out manually and not closing down the browser. Or open a new tab and opening the same address.
you can try to store the cookies and apply them to your new firefox instance
get the cookies using:
Set<Cookie> cookies = driver.manage().getCookies();
and than apply them to your new webdriver instance:
for(Cookie cook : cookies) {
driver.manage().addCookie(cook);
}
I have a big problem with Internet Explorer 7 and 8.
SITUATION:
I have a FORM that build a Medical Prescription. When I hit the save button, the script saves the DomainObject on DB and set a boolean property (of panel where the form is added) called "saved" to true and a byte[] property called PDF with bytestream.
On RenderHead of Panel, I read this boolean and, if is true, I force the trigger of a hidden button with this code:
String js = "$('#" + printPDF.getMarkupId() + "').click();";
response.renderOnDomReadyJavaScript(js);
The button executes this code:
ResourceStreamRequestHandler handler = new ResourceStreamRequestHandler(new ByteArrayResourceStream(pdf, "application/pdf"));
handler.setFileName("foo.pdf");
RequestCycle.get().scheduleRequestHandlerAfterCurrent(handler);
This code work perfecly on FF and Chrome. The Browser download windows appears and the user can save the PDF on HD.
Unfortunally, Internet Explorer has that damn security behavior that is triggered when a site require something to download. That warning require a user validation. A yellow Bar appear and the user is force to hit "Download".
screenshot http://imageshack.us/a/img198/1438/securityg.jpg
When I hit Download File, the form is submitted again with the exact state I had when I hit save the first time. So no previous INSERT on DB is already committed; The Session is resetted to the previous state etc...
The result is a double INSERT on DB of the Domain Ojbect.
Any clue to resolve this?
The problem is that you click download link programaticly instead to redirect browser to an URL or open an URL by JS window.open(url). Click a link looks like an unwanted operation that is sometimes restricted by browser.
This is a weird bug, and I'm not even sure how to begin figuring out what's going on.
We are using Cake 1.3.8 with our sessions in the database. I am not using ACL or any other access control. If we navigate into the application and click around a bit, and then rapidly click the browser back button twice (I've tried in Firefox and Chrome) the user is logged out more often than not and receives the error message 'You are not authorized to access that location'.
All of my searches thus far have involved people wanting to make the page inaccessible if a user logged out and then used the back button. I'm not seeing anything reported with regards to the issue I'm seeing.
Does anybody know if this is a Cake issue or have any thoughts on debugging what is going wrong?
Update: I found where the problem is. I have the security set to high, because we need the session to be closed whenever somebody closes the browser. I also have the timeout set very high because we do large binary uploads to S3, and don't want the user logged out while it's uploading or downloading. The specific block of code in cake_sessions.php that's causing the problem is:
$time = $this->read('Config.time');
$this->write('Config.time', $this->sessionTime);
if (Configure::read('Security.level') === 'high') {
$check = $this->read('Config.timeout');
$check -= 1;
$this->write('Config.timeout', $check);
if (time() > ($time - (Security::inactiveMins() * Configure::read('Session.timeout')) + 2) || $check < 1) {
$this->renew();
$this->write('Config.timeout', 10);
}
}
$this->valid = true;
I would guess this is because session IDs are regenerated between requests when security = high. Source:
http://book.cakephp.org/compare/44/CakePHP-Core-Configuration-Variables/cakephp/cakephp1x
You only need one out of sync request, say for a missing image and you will lose the session. I've generally found it unworkable because it's not possible to prevent users double-clicking on links and buttons and invalidating their session.
I would think about using medium security, setting the session timeout fairly short and using an AJAX script to refresh the session at regular intervals (eg every 60s). That way the user will be logged out quickly if the tab/window is closed.
If security is a priority I would suggest hacking the core to make sure the session cookies are set to http_only to help guard against session hijacking by XSS attacks. Cakephp 1.x supports PHP4 so probably isn't setting this by default.
http://php.net/manual/en/function.setcookie.php
It's possible that the session is erased and before it can be written again, the back button is clicked removing the auth from the session variables.
Page loads -> Back Button Clicks -> sessions is erased (but before session is rewritten) -> Back button clicks -> Session checks no existing session.
The only thing that I can think is happening is that when you're going back a page too quickly your code can't validate the person quickly enough (round trip from checking credentials) and throws an error that gets displayed on the next page that is loaded (second backed-to page).
Are you sure the person is actually logged out, or is it just the error being thrown?
Without seeing any code, it will be difficult to nail it down any further.