I have an application which stores the signed_request in the session on initial load. The reason is to access the data without having to append ?signed_request to all internal links.
I need to differentiate the view depending on if the user has liked the page or not.
Is there anyway I can bind an action, say an event handler that via ajax flushes my sessions? Or am I missing something obvious?
I ended up adding certain logic to my front page,
13 if ( !isset( $_GET['fromnav'] ) ) {
14 unset( $_SESSION['fb_data'] );
15 }
16
17 include 'includes/sess.php';
Any links that go to my index.php from within any navigation/internally need to be appended with ?fromnav. This states that its internal instead of a fresh state. If it's a fresh state, I clear the session fb data and parse the signature fresh. This seems to work so far.
Related
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.
This question already has answers here:
Prevent user from seeing previously visited secured page after logout
(7 answers)
Closed 6 years ago.
I have a JSP page with a form where you fill up certain details. On submitting the form i call a servlet which then updates details in a database after that i redirect to a page i display a confirmation message to the user.
The problem i have here is when the user clicks back he goes to the form page again where if he clicks a submit button, it creates a new record in the database.
Consider this similar to a shopping cart example where in this case he would buy the same item twice. But the only problem here is i cannot handle this in backend, i.e. the database can never know a redundant operation is taking place.
I need to handle this from the client side.Bit weird but i have to do it this way.
Basically when the user clicks the back button i don't want him to be able to go to the form page and may be just to some other page.
This is a typical HTML form issue, you can solve it through any one of following methods
1) Server side (page expiration): Since you've mentioned that the page refreshes and goes to the confirmation. You can set no-cache and add a page expiration time as -1 to the page you have that form.
So that when user presses the back button, he will see that the page has expired. He will be forced to load the page freshly. This is the behavior that I see in most banking websites.
Response.Buffer = True
Response.ExpiresAbsolute = Now() - 1
Response.Expires = 0
Response.CacheControl = "no-cache"
2) Using turn Key method: When the form loads, you can generate a random key in session memory and also embed it as a hidden value in the page.
During form submission, check the submitted hidden key against the value in session. If exists, then add the entry to database otherwise you can reload the page with a fresh key for the user (who might have done that unintentionally).
In load balanced or web farms, consider persisting the turn key in Database against the current user.
3) Client Side (Not recommended) : You can restrict the user from using the browser back button by removing the page from the history. (One side effect is that it will remove the entire history for that browser tab/window)
history.pushState(null, null, document.title);
window.addEventListener('popstate', function () {
history.pushState(null, null, document.title);
});
If you need the same support for older browsers where push and pop states are not supported, you can use following snippet.
<script>
function preventBack() {
window.history.forward();
}
setTimeout("preventBack()", 0);
window.onunload = function() {
null
};
</script>
Before redirecting to the JSP page send these headers with the response from the controller so that the page is not stored in cache and the browser will always request a new page from the server.
response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
response.setHeader("Pragma", "no-cache"); // HTTP 1.0.
response.setDateHeader("Expires", 0);
So every time you go back to that page a new page will be requested from the server and will be displayed with the cleared input fields.
You could implement a PRG-Pattern (https://en.wikipedia.org/wiki/Post/Redirect/Get) using php.
Basically, after successfully submitting the form you redirect to a confirmation page which informs the user that their submission was successful/accepted/etc. and also set a variable which you can later use to check if said submission has been submitted yet.
When the user tries to reload said page or go back you can check the variable and display either the form again or the confirmation page based on if the submission has been submitted already.
I think following flow is the best:
Client submits data to server
Servlet processes it
It returns HTTP 303 redirect to client
Client redirects to success page
After this flow, refresh, back button will work properly.
For more information read Simple Post-Redirect-Get code example
I have two jsp page: page1.jsp with a form and page2.jsp which displays a message to tell the user if the record insert happened or not.
If the form is successfully submitted and the user refreshes the page2, another insert happens.
I wouldn't to use a session variable, and setting a request attribute in the page2 doesn't resolve the issue (it seems to not work).
You can give a try to this:
From page1.jsp set a request attribute, when control reaches to
page2.jsp check for that request attribute if it is there redirect the
control to same page2.jsp. In this way when control is redirected to
same or other resource, previous request and response objects are no
more there(i.e. both request and response object will destroy because
HTTP is stateless protocol) And like this after redirection there will
be no data related to previous request and on refreshing the page2.jsp it
will not repeat the previous task.
I am not sure but in one of my application I used the same for the purpose. Let me know if anyone has a better alternative.
I am wrestling with the PayPal service . I almost have it done . Last step, when the customer payed and has the last page, which stays open for 10 seconds and then redirects them to the page of your choosing.
What parameters, posts, etc are sent with that page opening? And how do I get access to them, so I can link the returning user with their created account (from ipn and my personalized database entry on the initial buyitnow)
I tried echo($_post). But it just shows .... Array() But no key value pairs.
I'd think there would be a lot more
I have rm=2. Set already.
Plus, I see some Get() cars in the URL but, nothing I can use .
Also, I am passing a custom variable , which is going through, and being used by the IPN to update the user account just fine. I just don't see how to connect the return page and the customer, preferably with the $custom var
Help?
Try using var_dump($_POST); instead of echo($_post);
Apparently, there are no POST variables coming from PayPal, they're all GET variables. A VAR_DUMP(GET) will show like 6 things, including your CUSTOM variable (id cm). I thought there would be more and it would be in POST format.
I also thought there would be a way to show everything, POST, GET, SESSION, etc. I even tried using Firefox NETWORK setting, but there were like 50 separate items. None of which seemed to contain my data. I'm sure it was there, but, hidden.
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.