I found an Ajax service running as I called my Event tracker calendar.
[myserver]/tiki-tracker_calendar-list?trackerId=30&beginField=startDate&endField=endDate&resourceField=title&coloringField=null&filters=%0D%0A%7Bfilter%20field%3D%22tracker_field_eventCategory%22%20content%3D%22%22%7D%0D%0A&start=1488085200&end=1491710400&_=1490626987241
If the attacker leverage this and enter:
tiki-tracker_calendar-list?trackerId=30&beginField=startDate&endField=endDate&start=0&end=9999999999
The system will return all the events in tracker 30.
I tried to enter:
`if (! isset($user))
{
header('Location: index.php');
die;
}`
in File: /var/www/html/tikisvn15/tiki-ajax_services.php
At line 35
It works. Is there any other way? Would my modification stop the Ajax service from other components?
You can set which groups can see what using the Tiki permissions system. See the documentation here
Note that once you have set your tracker not to be visible for anonymous (not logged in) users you will need to rebuild your search index (on Control Panels -> Search) because TrackerCalendar uses the search index extensively.
I would advise against putting arbitrary user checks like this in the tiki code as things will stop working and it will be very hard to work out why, i think.
Related
I've been playing around with building some realtime functionality using Sails.js version 0.10-rc5 (currently the #beta release).
To accomplish anything, i've been following the sweet SailsCast tutorial on this subject (sailsCast link)
It talks about subscribing to a model via a 'subscribe' action within the model's controller. Then listening to it at the client side, waiting for the server to emit messages. Quite straightforward, although I do not seem to receive any messages.
I'm trying to do this to get real-time updates on anything that changes in my User models, or if new ones get created.. So I can display login status etc. in real time. Pretty much exactly the stuff that's explained in the sailsCast.
In my terminal i'll get two things worth noticing, of which the first is the following:
debug: Deprecated: `Model.subscribe(socket, null, ...)`
debug: See http://links.sailsjs.org/docs/config/pubsub
debug: (⌘ + double-click to open link from terminal)
debug: Please use instance rooms instead (or raw sails.sockets.*() methods.)
It seems like the 'subscribe' method has been deprecated. Could anybody tell me if that's correct, and tell me how to fix this? I've been checking out the reference to the documentation in the debug message, although it just points me to the global documentation page. I've been searching for an answer elsewhere, but haven't found anything useful.
The second message I'm getting is:
warn: You are trying to render a view (_session/new), but Sails doesn't support rendering views over Socket.io... yet!
You might consider serving your HTML view normally, then fetching data with sockets in your client-side JavaScript.
If you didn't intend to serve a view here, you might look into content-negotiation
to handle AJAX/socket requests explictly, instead of `res.redirect()`/`res.view()`.
Now, i'm quite sure this is because I have an 'isAuthenticated' policy added to all of my controllers and actions. When a user is not authenticated, it'll redirect to a session/new page. Somebody must log in to be able to use the application. When I remove the 'isAuthenticated' policy from the 'subscribed' action, the warnings disappear. Although that means anyone will get updates via sockets (when I get it to work), even when they're logged out. - I don't really feel like people just sitting at the login screen, fishing out the real time messages which are intended only for users who are logged in.
Can anyone help me getting the real time updates to work? I'd really appreciate!
As far as the socket messages not being received, the issue is that you're following a tutorial for v0.9.x, but you're using a beta version of Sails in which PubSub has gone through some changes. That's covered in this answer about the "create" events not being received.
Your second issue isn't about sockets at all; you'll just need to reconsider your architecture a bit. If you want to to use socket requests to sign users in, then you'll have to be more careful about redirecting them because, as the message states, you can't render a view over a socket. Technically you could send a bunch of HTML back to the client over a socket, and replace your current page with it, but that's not very good practice. What you can do instead is, in your isAuthenticated policy, check whether the request is happening via sockets (using req.isSocket) and if so, send back a message that the front end can interpret to mean, "you should redirect to the login page now". Something like:
module.exports = function (req, res, next) {
if ([your auth logic here]) {
return next();
}
else {
if (req.isSocket) {
return res.json({status: 403, redirectTo: "/session/new"});
} else {
return res.redirect("/session/new");
}
}
}
I'm new to Fiddler and have run across something that seems strange to me. If I select an entry and then click Replay, I get different behavior from when I drag an entry into the Composer window and click Execute.
Should the different behavior between these two methods of re-making a request be different?
Note: I called the second method "cloning" a request because the Composer window says "You can clone a prior request by dragging and dropping a session from the Web Sessions list)."
What is the "different behavior" specifically?
The two operations you describe should behave the same way unless the server returns a redirect or an authentication challenge, in which case preferences will control whether Fiddler automatically authenticates and/or follows the redirect.
Please feel free to email me (Help > Send Feedback) details and/or screenshots of the difference you see.
One of our clients wants to FE log in as two different users at the same time, using one browser. I think this is only possible when using two different browser. IS there any workaround?
Background is this: We wrote a FE extension where user can login and update some of their data. One client is a kind of superuser/admin. He wants to compare and edit data of several users at once.
Authentication in TYPO3 is performed by cookie fe_typo_user and therefore it is not possible to have two users logged in at same time from same browser.
You may advise to use different browsers or virtual machines for your client.
As Viktor wrote - it's not possible. Here I should finish the answer.
Anyway... while you are creating your own plugin you can easily add 'simulate mode' using for an example custom cookies... Block schema is:
[IF isAdmin AND simulateMode == false] {
Display admin's version
} [ELSE] {
Display common user's version
}
You can go even farther and switch the admin to simulate some chosen 'common' user, anyway make sure that will not violate some privacy police.
I would like to know if Google Analytics automatically keeps track of the pages that have their state retained using the ajax history token ('#'), developed for example with GWT.
My app has a single html page and different modules (pages) have the same URL, except that part that comes after # (ex. www.mysite.com?test=true#page=Contacts/id=1).
Also, if this mentioned behavior is not by default, is there a way to set up the Google Analyics to have this functionality ?
EDIT:
I found this article which explains how #hashtag can be tracked:
http://www.searchenginepeople.com/blog/how-to-track-clicks-on-anchors-in-google-analytics.html
But, if i use this solution, will the page access be recorded when a user presses an Anchor with href'#hastag' or only when a a page is accessed directly with that hashtag (in that case, I should register a function that calls trackPageview when history changes)?
Google tracks the # just fine. You just need to take it actually receives the # as-is (in our case the # got url-encoded to %23 and we had to use a search-and-replace-filter to restore it).
The most elegant way would be probably to look in GA admin into the instructions for the advanced filter - there is a nice example how to rewrite obscure URls into something readable by humans in the reports, which could be easily adapted for your needs.
I added the following lines to the initial analytics script:
_gaq.push(['_trackPageview', location.pathname + location.search + location.hash]);
and
window.onhashchange = function(){
_gaq.push(['_trackPageview',location.pathname + location.search + location.hash]);
}
which tracks the history change.
I'm writing a Catalyst application that's required to have a fairly short session expiration (15 minutes). I'm using the standard Catalyst framework authentication modules, so the user data is stored in the session -- i.e., when your session expires, you get logged out.
Many of the uses of this application will require >15 minutes to complete, so users will frequently submit a form only to find their session state is gone and they're required to log back in.
If this happens I want to preserve the original form submission, and if they log in successfully, continue on and carry out the form submission just as if the session had not expired.
I've got the authentication stuff being handled by an auto() method in the controller -- if you request an action that requires authentication and you're not currently logged in, you get redirected to the login() method, which displays the login form and then processes it once it's submitted. It seems like it should be possible to store the request and any form parameters when the auto method redirects to the login(), and then pull them back out if the login() succeeds -- but I'm not entirely sure of the best way to grab or store this information in a generic/standard/reusable way. (I'm figuring on storing it in the session and then deleting it once it's pulled back out; if that seems like a bad idea, that's something else to address.)
Is there a standard "best practices" or cookbook way to do this?
(One wrinkle: these forms are being submitted via POST.)
I can't help thinking that there's a fundamental flaw in mandating a 15 minute timeout in an app that routinely requires >15 minutes between actions.
Be that as it may, I would look at over-riding the Catalyst::Plugin::Session->delete_session method so that any contents of $c->request->body_parameters are serialised and saved (presumably to the database) for later recovery. You would probably want some rudimentary check of the POST arguments to ensure they're what you're expecting.
Similarly, create_session needs to take responsibility for pulling this data back out of the database and making it available to the original form action.
It does seem like a messy situation, and I'm inclined to repeat my first sentence...
UPDATE:
Whether you use delete_session or auto, the paradoxical issue remains: you can't store this info in the session because the time-out event will destroy the session. You've got to store it somewhere more permanent so it survives the session re-initialization. Catalyst::Plugin::Session itself is using Storable, and you should be able to with something along these lines:
use Storable;
...
sub auto {
...
unless (...) { #ie don't do this if processing the login action
my $formitems = freeze $c->request->body_parameters;
my $freezer = $rs->update_or_create(
{user => $c->user, formitems => $formitems} );
# Don't quote me on the exact syntax, I don't use DBIx::Class
}
...
my $formitems = $c->request->body_parameters
|| thaw $rs->find({$user => $c->user})->formitems
|| {} ;
# use formitems instead of $c->request->body_parameters from here on in
The underlying table probably has (user CHAR(x), formitems TEXT) or similar. Perhaps a timestamp so that nothing too stale gets recovered. You might also want to store the action you were processing, to be sure the retrieved form items belong to the right form. You know the issues for your app better than me.
I would store the form data as some sort of per user data in the model.
Catalyst::Plugin::Session::PerUser is one way of doing that (albeit somewhat hackishly). I would reccomend using the session plugin only for authentication and storing all the state info in the model that stores your user data instead.
And I totally agree with RET's opinion that the 15 minute limit seems really counter productive in this context.
I came across this whilst searching CPAN for something entirely unrelated.
Catalyst::Plugin::Wizard purports to do exactly what you need. The documentation suggests it can redirect to a login page whilst retaining the state of the previous action.
NB: I haven't used it, so can't vouch for its effectiveness.
In the end, we ended up grabbing the pending request (URL+params) in the auto(), serializing and encrypting it, and passing it via a hidden form element on the login page. If we got a login request with the hidden element populated, we decrypted and deserialized it and then redirected appropriately (making sure to pass through the standard "can this user do this thing" code paths).
You could always have some javascript on the client that keeps the session from expiring by making a small request every few minutes.
Or you could have AJAX check for an active session before posting the form and presenting the user with a new login box at that time if needed.