I'm working on a web-project which uses GWT on client and Java on server side (tomcat7).
If cookies are enabled on the browser, everything works fine. I can use sessions without any problems.
If cookies are disabled on the browser, sessions doesn't work.
I guess, this his mainly something to do with GWT apps being a single web-page application which only requests data from the server via ajax.
Is there a way to get sessions working under such circumstances?
Help is very appreciated!
All the best,
Thomas
If you using GWT RPC, you will need to modify your RPC urls to burn in the jsessionid as discussed in this forum post. Though I am not sure if line Cookies.getCookie("JSESSIONID") as shown the forum post will work in your case. You might need to parse the location.href
On the server side you can access the session as follows:
public class NameImpl extends RemoteServiceServlet implements NameService {
public void doSomething() throws IllegalArgumentException{
HttpSession hs = this.getThreadLocalRequest().getSession();
//Do whatever it is you want to do with this information.
}
}
Not 100% sure that if is what you are asking for, but it seems like the most reasonable answer.
Related
I'm facing some issues while trying to work with cookie in distincts domains. In my scenario I have two apps (app1 and app2). Basically, the app1 is doing an ajax request to the app2 in order to this one creates a cookie (i.e. dummyCookie). The app2 is an application running over the Play framework 2.5 for Java. I'm creating the cookie like this:
response().setCookie(Http.Cookie.builder("dummyCookie", "9e0a6b4c-58ed-b700-0000-015ec494956").build());
I'm using the plays's CORSFilter:
package myCustomFilters.filters;
import play.filters.cors.CORSFilter;
import play.http.DefaultHttpFilters;
import javax.inject.Inject;
public class Filters extends DefaultHttpFilters {
#Inject
public Filters(CORSFilter corsFilter) {
super(corsFilter);
}
}
In my application.conf I have this configuration:
play.http.filters = "myCustomFilters.Filters"
play.filters {
cors {
pathPrefixes = ["/"]
allowedOrigins = null
allowedHttpMethods = ["POST, GET, PUT, DELETE, OPTIONS"]
}
}
In the Chrome's console, in the Network tab, I could see the cookie in the response header.
If I check the Application tab, Cookies session, I couldn't see the cookie there:
I did some investigations and maybe the problem is related to the scenario "CORS + AJAX", since that I have one application calling (via ajax request) the another one to generate a cookie.
Guys, somebody already faced with this kind of scenario?
I had similar issues. I had to tweak the configuration in different ways to make that work in Chrome. And client request also need some specific changes (I use JQuery, and this kind of approach was necessary : Sending credentials with cross-domain posts?).
However, in the end, I discovered that Safari would most likely never work for me, as Apple now has specific rules to handle when cookies can be sent cross domain or not. Depending on what you are trying to achieve, this might lead you to consider a totally different approach.
I am building stateless restfull API in Yii2. So I created new APP in my advanced app layout (as preferred by Yii2 creators) and configure all necessary things and API worked.
Now I want to make it stateless - I want to disable session and I want it to be accomplished in config/main.php inside my API app to ensure it as global setting.
Also I want to disable cookies and auto login.
What I have been playing now so far is inside Module class
<?php
namespace api\modules\v1;
use \app\models\User;
use yii\filters\auth\HttpBasicAuth;
class Module extends \yii\base\Module
{
...
public function init()
{
parent::init();
\Yii::$app->user->enableSession = false;
\Yii::$app->user->enableAutoLogin = false;
}
...
}
But when trying to access data using POSTMAN on Chrome I can see that:
Cookies are set (PHPSESSID, _csrf, _identity)
I always get popup asking for username and password
Thanks for your help in advance!
Finally I found out what the problem is. Yii2 worked OK, but Postman had some data stored from the past when cookies and session were enabled. What helped me was deleting browser's history (including cookies), close all instances of browser and rerun.
I'm using wicket 6.
My application is based on WebPages created with pageParameters in the constructor. I'm using also a pageParameter country that is a path-parameter defined with:
mountPage("/${country}/pagepath", MyPage.class);
I have many statefull forms in every page.
I'm now trying to handle the case when the session expires (to reproduce this scenario I delete or modify the jsessionid cookie).
After that I click a submit button in a page and I'd expect wicket to understand that the session has expired.
But the behaviour that I have is this:
the current page is reloaded but the pageparameters are 'null'
the url is rewritten using the package notation like:
localhost:8080/wicket/bookmarkable/com.test.pages.MyPage
So it looks like the url mapping is somehow lost.
I need to reload the same page with pageParameters information or show an info page that says something like click here to reload.
I've already tried to use:
getApplicationSettings().setPageExpiredErrorPage(HomePage.class);
but that didn't help.
Any help is appreciated. Thanks.
Looks like there is a bug in Wicket 6 which causes this issue: https://issues.apache.org/jira/browse/WICKET-5068
It is fixed in Wicket 7. For Wicket 6, there is a workaround: disable WICKET-4594 fix.
First add the following mapper:
public class BookmarkableMapperThatSavesPageParametersForListener extends BookmarkableMapper {
#Override
protected PageParameters getPageParametersForListener(PageInfo pageInfo, PageParameters pageParameters) {
return pageParameters;
}
}
Then use it to replace a built-in BookmarkableMapper in your Application#init() (this has to be added before any manipulations with the root mapper):
mount(new BookmarkableMapperThatSavesPageParametersForListener());
This approach works in our application and it does not seem to break anything.
More info: Wicket 6: empty PageParameters when recreating a page after expiration
You could ask your question in the wicket mailing list. What you are observing might be a bug. Please check PageParameters missing from re-created Page
Conceptually, it should be possible to submit the form normally even if you need an authenticated user session.
If the session is expired then you may be able to re-create a user session with a remember-me cookie. Wicket should re-construct the page with parameters, apply the form values and process the submit. In case where the page is stateful, there could be some complications that are possibly resolvable. If you find that your use case is not supported with stateful pages then you could file an issue and meanwhile use StatelessForm.
I'm trying to get my MVC3 site to redirect from HTTPS back to HTTP when the user browses to a page where it's not required (and they aren't logged in). I Don't want to have the load of running the whole site HTTPS but it's looking like thats the way I'll have to go.
I've been having loads of trouble with remote debug and symbols, but having gone back in time to 1985 and using message box equivalents to debug with I've come to the following conclusion:
if (filterContext.ActionDescriptor
.GetCustomAttributes(typeof(RequireHttpsAttribute), true)
.Any()
)
{
return true;
}
return false;
Always returns false.
The controller def starts as:
[FilterIP(
ConfigurationKeyAllowedSingleIPs = "AllowedAdminSingleIPs",
ConfigurationKeyAllowedMaskedIPs = "AllowedAdminMaskedIPs",
ConfigurationKeyDeniedSingleIPs = "DeniedAdminSingleIPs",
ConfigurationKeyDeniedMaskedIPs = "DeniedAdminMaskedIPs"
)]
[RequireHttps]
public class AccountController : Controller
{
And it doesn't seem to work for any actions in this controller (although they do get successfully routed to SSL).
Any suggestions? I'd love to see an answer for what I perceive as my own nubery ;)
Custom NotRequreHttpsAttribute tutorial
I use the above link post to implement my custom attribute, and redirect from https to http. Hope this helps.
My problem was discovered to be related to the bindings on the server published to. We use the same server for stage and production, and the stage https bindings were not set, so whenever it was calling an https page it was resolving into our production site (which looked the same so it was hard to spot).
Once I added a binding it was all solved. My code was ok...
I'm using mvc-mini-profiler along with Glimpse. The problem is glimse is flooding the profiler output with glimpse requests. Is there any way to ignore all request made by glimpse ?
protected void Application_Start()
{
var ignored = MiniProfiler.Settings.IgnoredPaths.ToList();
ignored.Add("Glimpse.axd");
MiniProfiler.Settings.IgnoredPaths = ignored.ToArray();
}
Solution Posted here:
Mini MVC profiler: appears to be displaying profile times for every static resource
At the moment Glimpse will make Ajax requests if you have the Remote tab selected or when ever an Ajax request is made by your site.
This is done because when we detect that a request is made we proactively get the Glimpse data. We could probably switch this in a future release to be more lazy and only fetch the data on request.
Note, even though this will help, Glimpse will still be calling back to the server in the same way that Mini Profile does. Hence, both frameworks could probably try and ignore each other for ajax requests.
Hope this helps.