man, I am stumped, and you probably won’t be able to help, but perhaps if I talk it through here:
This is a CodeIgniter custom CMS.
I am troubleshooting a custom cms someone else wrote; specifically, one of the payment gateways (HSBC - similar type library as PayPal or the like, but using Curl )
It has a callback function from the bank’s site, returning a set of $_POST variables.
PROBLEM: The $_POST variable are not accessible from app’s controller (I can see them returned by using httpFox)
I CAN:
1) return to a non-app .php page and print_r($_POST) (i.e., callback url is just another page on my server, outside of CI)
2) post a Form from within or outside the app to the suspect controller, and print_r($_POST) with no trouble (i.e., this controller/app CAN receive a normal post)
So, trying to read the $_POST results from the callback itself is what is failing.
Any ideas on what to check, or how to track this? It’s obviously some setting somewhere, perhaps with Curl, but I’m at a loss. Happy to post code/more info once I figure out what direction to go in
TIA,
jeff
Getting POST variables in CodeIgniter is acheived through the input class.
The documentation states that all the superglobal variables are destroyed.
Getting the content of $_POST['something'] should then be done by:
$something = $this->input->post('something');
ok, a little closer observation final tracked it down:
the previous developer had the .htaccess to first add a trailing slash, then remove the .index.php?
it seems the callback was being routed to itself and as part of the process (along with some config settings, maybe) was losing the post vars. not sure if that's a precise description, but it was routing twice through the system
thanks
Related
I have a listing page for an e-commerce website with various items (item_list.php). This page is generated with a PHP loop and displays each item inside a <li> element. Every item is a link to the same page, called item_details.php .
When clicking on the link i want to run a script that changes a SESSION var to a certain $id (which will be excracted from the <li> itself with .innerHTML function) and then allowing the browser to move into the next page (item_details).
This is needed so i can display the proper information about each item.
I think this is possible with Ajax but I would prefer a solution that uses JS and PHP only.
(P.S.This is for a University project and im still a PHP newbie, i tried searching for an answer for a good while but couldn't find a solution)
No JS or other client-side code can set session values, so you need either an ajax call to php, or some workaround. This is not a complete answer, but something to get you thinking and hopefully going on the project again.
The obvious answer is just include it in the link and then get it in PHP from the $_GET -array, and filter it properly.
item title
If, however, there is some reason this is not a question with an obvious answer:
1.) Closest what you're after can be achieved with a callback and an ajax call. The idea is to have the actual link with a click function, returning false so the link doesn't fire at once, which also calls an ajax post request which finally will use document.location to redirect your browser.
I strongly advice against this, as this will prevent ctrl-clicks causing a flawed user experience.
Check out some code an examples here, which you could modify. You will also need an ajax.php file which will actually set the session value. https://developers.google.com/analytics/devguides/collection/analyticsjs/enhanced-ecommerce#product-click
2.) Now, a perhaps slightly better approach, if you truly need to do this client-side could be to use an click handler which instead of performing an ajax call or setting session directly, would be to use jQuery to set a cookie and then access this data on the item_list.php -page.
See more information and instructions here: https://www.electrictoolbox.com/jquery-cookies/
<script>
$('product_li a).click(function(){
$.cookie("li_click_data", $(this).parent().innerhtml());
return true;
});
</script>
......
<li class="product_li">your product title</li>
And in your target php file you check for the cookie. Remember, that this cookie can be set to anything, so never ever trust user data. Test and filter it in order to make sure your code is not compromised. I don't know what you want to do with this data.
$_COOKIE['li_click_data'];
3.) Finally, as the best approach, you should look at your current code, and see if there is something you can re-engineer. Here's a quick example.
You could do the following in php to save an array of the values in the session on each page load, and then get that value provided you have some kind of id or other usable identifier for your items:
// for list_items.php
foreach($item as $i) {
// Do what you normally do, but also set an array in the session.
// Presuming you have an id or some other means (here as item_id), to identify
// an item, then you can also access this array on the item_details -page.
$_SESSION['mystic_item_data_array'][$i['item_id]] = $i['thedata'];
}
// For item_details.php
$item_id = // whatever means you use to identify items, get that id.
$data_you_need = $_SESSION['mystic_item_data_array'][$item_id];
Finally.
All above ways are usable for small data like previous page, filters, keys and similar.
Basically, 1 and 2 (client-side) should only be used, if the data is actually generated client-side. If you have it in PHP already, then process it in php as well.
If your intention is to store actual html, then just regenerate that again on the other page and use one of the above ways to store the small data in case you need that.
I hope this gets you going and at least thinking of how to solve your project. Good luck!
I really hope my question has been well thought out but here goes.
How do you implement something like
Route::get("/url1", "controller#method");
Route::get("hello/url1", "controller#method");
Route::get("hello/hi/url1", "controller#method");
in Laravel but using something like
Route::get("*/url1", "controller#method");
instead of declaring every route path?
I will explain why this problem has come up. You see the primary url is always changing because its being called from a js file via a location.href call. I could decide to use a primary url variable but its to be deployed via intranet to different servers in organizations and the primary url could change at any time meaning that localhost/project on one system might become localhost:7987/project on another thus breaking the url variable, now thats on one part. On the other hand there are js functions running continuously and when someone navigates to a deeper url, say from localhost/home to localhost/home/event a route call that should be independent of folder breaks
So yeah, I am wondering if theres a way to declare a global route that points to a controller and/or if this is possible in Laravel.
Thanks
Try this:
Route::get('{something}/url1', 'controller#method')->where('something', '*');
Not sure if that will work, but the idea is that you can use where to pass some Regexp to match selected value from route.
Scenario:
I have a Board model in my Rails server side, and an Android device is trying to post some content to a specific board via a POST. Finally, the server needs to send back a response to the Android device.
How do I parse the POST manually (or do I need to)? I am not sure how to handle this kind of external request. I looked into Metal, Middleware, HttpParty; but none of them seems to fit what I am trying to do. The reason I want to parse it manually is because some of the information I want will not be part of the parameters.
Does anyone know a way to approach this problem?
I am also thinking about using SSL later on, how might this affect the problem?
Thank you in advance!! :)
I was trying to make a cross-domain request from ie9 to my rails app, and I needed to parse the body of a POST manually because ie9's XDR object restricts the contentType that we can send to text/plain, rather than application/x-www-urlencoded (see this post). Originally I had just been using the params hash provided by the controller, but once I restricted the contentType and dataType in my ajax request, that hash no longer contained the right information.
Following the URL in the comment above (link), I learned the how to recover that information. The author mentions that in a rails controller we always have access to a request variable that gives us an instance of the ActionDispatch::Request object. I tried to use request.query_string to get at the request body, but that just returned an empty string. A bit of snooping in the API, though, uncovered the raw_post method. That method returned exactly what I needed!
To "parse it manually" you could iterate over the string returned by request.raw_post and do whatever you want, but I don't recommend it. I used Rack::Utils.parse_nested_query, as suggested in Arthur Gunn's answer to this question, to parse the raw_post into a hash. Once it is in hash form, you can shove whatever else you need in there, and then merge it with the params hash. Doing this meant I didn't have to change much else in my controller!
params.merge!(Rack::Utils.parse_nested_query(request.raw_post))
Hope that helps someone!
Not sure exactly what you mean by "manually", posts are normally handled by the "create" or "update" methods in the controller. Check out the controller for your Board model, and you can add code to the appropriate method. You can access the params with the params hash.
You should be more specific about what you are trying to do. :)
We usually follow the convention of doing a redirect after every post, which is ideally very clean. But usually there is a requirement to give the user feedback about what has been updated.
When i do a post followed by get i wanna show the same page with the notification about the updation being done, which makes the GET very clumsy with the extra status of whats being updated. Am i missing something here?
which is ideally very clean
debatable.
which makes the GET very clumsy with the extra status of whats being updated
...and that's one of the main reasons why.
Trying to pass transactional data via the session is a very bad practice.
The solution I've used is to use a front controller for sequences of forms (not a front controller for the whole site!) but in general trying to avoid the scenario where there is a sequence of forms to be posted
I'm kind of new with CodeIgniter and I'm still learning (a lot).
So I have a view and when I submit a form I 'call' the controller by surfing to the right URL dynamically e.g. site/delete
class Site extends Controller {
function index(){$this->load->view('...')}
function delete() {
$this->site_model->delete_row();
$this->index();
}
}
Now when that action is done (deleted the row) I'm calling $this->index(); to redirect to my initial page (which is good) but my url stays: site/delete . I want my URL to be ../site/index (or without the /index)
Any help would be appreciated :-) .
So far I found something to solve this:
instead of:
$this->index();
I'm using:
redirect('site');
Does anyone know this is a good practice?
Redirect is what you should use.
In the user guide:
http://codeigniter.com/user_guide/helpers/url_helper.html
they use it after checking if a user is logged in. Depending on if they are or not, they redirect to a different place.
Also, note that any code after the redirect won't run. Make sure and redirect after you've done everything you need to.
My preferred method is to have actions like that handled by the same method that will be seen by the user afterwards.
What if you go to /site/delete afterwards, as a user? It will either have to detect and throw a error (show a message) or redirect to an appropriate page. /site/delete has no meaning.
For example, if a user would normally see an overview after deleting, then my form will be posted to /site/index; with index quickly checking for the condition and calling _delete() in the same controller, before doing its normal work.
That way, if the user refreshes the page, or presses 'back', things should look consistent to them.
Another example would be that /settings/edit would post to itself - this means that it can act on the post and show any output (e.g. validation errors). It means there's no /settings/do_edit location on my site, and also means that the user can go back to /settings/edit safely, and see a form for editing their settings.
I suppose this is a subjective take on a perhaps objective question, and I would encourage feedback on my view, but it's my way of avoiding the problem you have asked about.
$this->index();
Call of function in a function simply execute the functionality within that function.
And url never changed.
for changing the url you should use.
redirect ( base_url().'site');
but you should load url helper in constructor.