In eXist 4.7 I implemented the persistentlogin in my controller.xql and I have noticed that it does not "persist" very long in my eXist web app ("thema"), whereas the eXide web app in the same eXist instance, using the same login function, persists authenticated status as expected.
Specifically, if I am logged in to both in the evening, the next morning eXide is still logged in (ie. authenticated = true), and my app is not.
I implemented it as follows, with duration set at 30 days ("P30D"):
import module namespace login="http://exist-db.org/xquery/login" at "resource:org/exist/xquery/modules/persistentlogin/login.xql";
let $duration := request:set-attribute("duration", "P30D")
let $set-user := login:set-user("org.exist.thema", (), false())
So I've further tested the persistence in my web app and I find that the login "disappears" (loses authentication?) after about an hour of being non-active on the site.
Is there some other eXist setting I've missed in configuring this?
The only documentation I've been able to find on this is in the notes in the code of login.xql: https://github.com/eXist-db/exist/blob/develop/extensions/modules/persistentlogin/src/main/resources/org/exist/xquery/modules/persistentlogin/login.xql
According to the source code for the login module, there are two ways to designate the duration for the login session:
Via the $maxAge parameter of the login:set-user function
Via a duration request parameter (which overrides the $maxAge parameter when present)
In your code, you are setting a duration request attribute, not a request parameter; for more on the difference, see this answer. This explains why the login module is completely ignoring your attempts to declare a duration.
To fix your problem, you could either (1) change to the first method:
login:set-user("org.exist.thema", xs:dayTimeDuration("P30D"), false())
... or (2) submit the request parameter in your login form, as eXide does in its login form; see https://github.com/eXist-db/eXide/blob/master/index.html.tmpl#L505-L528.
Related
I've been using your advice and View::sharing all of my important data to all views. However, there is one issue I have encountered.
This code:
if(!Auth::guest()){
$user=Auth::user()->id;
}
else $user=0;
$temp=DB::select('query');
View::share('cartnumber', count($temp));
View::share('cartitems', $temp);
doesn't work when put in AppServiceProvider. Or better, it always sets $user=0, even if I am logged in. I thought it is because AppServiceProvider's boot function executes before the site checks if someone is logged in.
I then tried to use a BaseController with a construct function but that doesn't work either. The only solution that seems to work correctly is putting the code in every single Controller for every view! That actually works, which kind of confirms my theory.
But is there anywhere I can put this code without having to copy/paste it in every single Controller? Thanks in advance!
You'd likely want to put this code later in the request life cycle to guarantee an auth user because as others have mentioned middleware/session code has not occured during this part of the framework booting up. You could use a service class to call in all your controllers to avoid the copy pasting. Or If you'd like to achieve this using code in your service provider you could use a View Composer instead of a share this allows you to define a callback/or class that will be called right before the view is returned
view()->composer(['/uri-that-needs-data'], function ($view) {
if (Auth::check()) {
$cart = DB::query(...)->get();
$view->with('cartitems', $cart);
}
});
Check out https://laravel.com/docs/5.7/views#view-composers for more details.
Auth::user() will be empty until the session middleware has run.
The reason you can't access the user inside your service provider is because that code is run during the "bootstrapping" phase of the application lifecycle, when it's doing things like loading filesystem or cache drivers, long before the request is sent through response handlers (including middleware).
Once the application has been bootstrapped and all service providers
have been registered, the Request will be handed off to the router
for dispatching. The router will dispatch the request to a route or
controller, as well as run any route specific middleware.
Source: https://laravel.com/docs/5.7/lifecycle
If you don't want to copy/paste that code everywhere, then one place to put it is in custom route middleware. You can list it after the auth middleware to guarantee a logged-in user.
Edit: View composers are another really good option, as suggested by #surgiie. The reason these can be set up inside a service provider (unlike your example) is because the view composer registers a callback, but doesn't execute it until a much later stage in the application lifecycle.
I am new to meteor.js and I am sorry if my question is not appropriate according to the community standards.
Well, I am trying to create a simple application on it and came across a problem of timing out after the user inactivity.
I am using "stale session meteor package" to automatically timeout the user after some specified time of inactivity. It logs off the user but doesn't unset the "Meteor.user()" by which I could know in meteor that the user has been logged out and call the route for the "Login" page to re-login.
Example, the stale session logs off the user after 30 seconds of inactivity, then I checked the returned value of "Meteor.user()", It should have returned undefined if the stale-session is timed out, instead, it is running the complete user object with id and other details.
I simply want to forcefully logout the user when the stale session times out and show the login screen.
I have been searching on internet for two days but couldn't find any solution on how to do this. Finally, posted the question.
I have found the solution and it is working so posting it here if somebody need.
I dug into the stale package code, and in its client.js I replaced the code with this
Meteor.setInterval(function() {
if (Meteor.userId()) {
if(activityDetected){
Meteor.call('heartbeat');
activityDetected = false;
} else {
//This is the wanted behavior
Meteor.logout();
}
}
}, heartbeatInterval);
If no activity is detected in terms of jquery events, I simply call logout and dont need to worry about Meteor.user() or Meteor.userId() etc. It simply logs out and goes to the Login Screen route which I implemented.
I'm trying to test java web application (jsf) that uses oracle adf-faces. When I record my test, the application is working fine but when I later check the user, then on login.jsf page, just before authentication and home pages, I get 500 Internal server error that says:
ADF_FACES-30200:For more information, please see the server's error log for an entry beginning with: The UIViewRoot is null. Fatal exception during PhaseId: RESTORE_VIEW 1.
Some more info: My login.jsf page is referred by previous login page that has jsession id appended to it. However, as far as I understand, neoload automatically handles jsessionid (I did try to set a parameter for it though and it didn't fix the error)
Also login.jsf page itself is a referrer to authentication page that in its turn is a referrer to a home page of an application, and the latter are both redirect pages (do not use manual definition) so they are not played during the check because of this error:
login.jsf page uses POST method and it has the following POST parameters: pt1:username, pt1:password, org.apache.myfaces.trinidad.faces.FORM, Adf-Window-Id, javax.faces.ViewState, Adf-Page-Id, oracle.adf.view.rich.DELTAS, event, event.pt1:loginCommandButton
I use set of users (I have a variable for username and password) and I handle javax.faces.ViewState manually with a jsf parameter (it used to give me errors).
I would appreciate any help greatly!
Using latest version of cakephp v2.3.3
I have a problem with my session variables when a browser doesn't allow cookies.
I pass variables from one controller to the other and this works perfect as long as the browser has cookies enabled. I have tried it with the Session helper in the controllers, but no effort, same problem.
How to fix this, is there a work around???
Cookies are required to keep track of the session ID, but you can manually get or set the session ID using $this->Session->id(). By adding the code below to the App Controllers' before filter you can set the session ID as a URL paramter like http://example.com/posts/view/1?session=qkv108c2pqeubcpeos1q7ekds3, for example.
if (!empty($this->request->query['session'])) {
$this->Session->id($this->request->query['session']);
}
The session ID is required for every request which means you have to include it in every link. I would suggest extending the HTML helpers' url and link methods to automatically add it.
Edit:
You should verify that $this->Session->read('Config.userAgent'); or $this->request->clientIp(); has not changed since the user was authenticated to prevent session hijacking. Thanks to thaJeztah for pointing this out.
My host requires me to use a different domain for SSL secured access (shared SSL), so I need to transition the user session between two domains. One part of the page lives at http://example.com, while the SSL'd part is at https://example.hosting.com. As such I can't set a domain-spanning cookie.
What I'm trying to do is to transition the session id over and re-set the cookie like this:
http://example.com/normal/page, user clicks link to secure area and goes to:
http://example.com/secure/page, which causes a redirect to:
https://example.hosting.com/secure/page?sess=ikub..., which resurrects the session and sets a new cookie valid for the domain, then redirects to:
https://example.hosting.com/secure/page
This works up to the point where the session should be resurrected. I'm doing:
function beforeFilter() {
...
$this->Session->id($_GET['sess']);
$this->Session->activate();
...
}
As far as I can tell this should start the session with the given ID. It actually generates a new session ID though and this session is empty, the data is not restored.
This is on CakePHP 1.2.4. Do I need to do something else, or is there a better way to do what I'm trying to do?
When Configure::write('Security.level') is set to medium or higher, session.referer_check is implicitly activated, which makes the whole thing fail. Setting the security level to low (or using a custom session configuration) makes everything work as it should.
There went about 5 hours of debugging... ( -_-;;)
My first thought is to use the Cake file sessions and copy the file over, and then perhaps try and start a new session with that phpsessid, although I'm not even sure if that would actually work or not :)
With Cake 2.6.1 -- This is what worked for me.
$this->Session->id("tfvjv43hjmsnjkh0v3ss539uq7"); // add session id you want to set
$this->Session->id();
$this->Session->read("key"); // hhoorray worked :)
with SessionComponent id() function needs to be called twice once with session id to set session_id(); and second time to start cake session.
First call does not really start the session ... I dont know how Cake Guys missed it .....
Upvote if this works for you.