i'm using form filtering to filter data in the frontend.
The problem is that the URL is ugly
http://............./players/game/?st_player_cv_filters[location_id]=1&st_player_cv_filters[plateforme_id]=3&st_player_cv_filters[level_id]=3&st_player_cv_filters[_csrf_token]=023c5c9fb5fc7e7b6ed60d6839c36f67
(form rendered with :
<?php echo $form->renderFormTag(url_for("game_player", $game), array('method' => 'get')); ?>
<table><tr><th><label for="location_id"><?php echo __('Country'); ?></label></th><td><?php echo $form['location_id']; ?></td></tr>
How to render this url in a better way please ?
Thanks
Using the framework/API itself is a good idea if it supports your needs. By the sound of your question, you can likely use the Symfony routing API to faciliate a solution...
For example, this book chapter covers it:
How to configure the routing rules to
change the appearance of URLs
Futhermore it speaks about long querystrings that you mentioned:
For instance, a traditional URL
contains the file path to a script and
some parameters necessary to complete
the request, as in this example:
http://www.example.com/web/controller/article.php?id=123456&format_code=6532
and speaks about the associated problems:
The unintelligibility of URLs makes
them disturbing wherever they appear,
and they dilute the impact of the
surrounding content
The chapter provides HOW IT WORKS: examples of how to change your URLs using configuration and programming.
You should be able to maintain bookmarkability through easier to read/less complex/more secure URLs.
sometimes when I run into this problem I run a redirect from the receiving page for the form to itself using symfony's redirect method.
$this->redirect('.../formAction?'.http_build_query($get_vars));
OR
use the url_for() method and such as:
<form action="<?php echo url_for('.../formAction?'.http_build_query($get_vars)); ?>">
...
</form>
If you have the option, you could use POST rather than GET. That would clean up the url significantly.
Related
Is it good to use "required" in input like this:
Name:<input type="text" name="name" required>
Or should I remove it and use "isset" in PHP? If I understand properly, both show you error, when you want to proceed next without filling input's, but required just awares you, while isset throw's you mostly to new page and reset the form(not good if you only forgot to fill one input).
Or should I remove it and use "isset" in PHP?
Why do you feel the two are mutually exclusive? Use both.
The required HTML attribute provides a smoother client-side user experience. It allows some basic validation without having to re-engage the server. It does not, however, do anything to validate incoming requests in server-side code. isset (among lots of other potential logic) can and should be used server-side to do just that.
Use client-side validation logic to present users with a better user experience. Use server-side validation logic to actually validate the user input before conducting business logic. Validation can live in lots of places for lots of reasons.
I am not 100% sure if this is as big an issue has I seem to think it is right now but I think I may of found an issue or at else an hole within the Inspect Element viewer within Chrome.
I was using (I have now changed my settings) hidden ID's to set a number of defaults, one was users levels, another was to make the user active by default.
However when I view these ID's within the inspect Element view and then changed the values, submitting the form would submit the NEW value to the server and not the value I had given it.
For Example:
I had something like the following within my code,
<input type="hidden" name="data[user][level][id]" value="1" id="MyID">
I then changed it within the Inspect view to,
<input type="hidden" name="data[user][level][id]" value="2" id="MyID">
Then I submitted the form and was surprised that the NEW value was submitted, I was always under the inpresion that hidden ID's where not changeable and the browser should only submit the default values held within.
I have now changed this to letting the database default to a basic user and then I can change the users setting has I want to. But in some cases this may not be an option, so I was hoping for an answer or some feedback about how to make this more safe.
Am I just a bit slow, are there better methods (different ones) to passing 'hidden' data from forms to the server?
I was thinking about maybe using JQuery to add the needed hidden fields to the forms once the user had selected / submitted the form, but i am not sure if this is 100% safe or even if its a good idea.
Any ideas / feedback are very welcome.....
Many Thanks,
Glenn.
I had the same problem passing the database data into a modal,the solution i know is to use jquery ajax to get the informations from the database requesting a file,adding them into variables and compare the variables
$.ajax({
url: "test.html",
context: document.body
}).done(function() {
$(this).addClass("done");
});
I used this code sample to do it.
Of course there are a few modifications to be done depending on your script
I found a better way of doing this, at lest in CakePHP. The CakePHP framework has inbuilt security calls. These in-built functions when added give you all sorts of stuff but the main reason I used them was to stop this sort of form tampering.
I am not 100% sure how it does this, but it adds a token to all forms and it checks to see if the form being submitted is right? Again not sure how the token works.
But here is the code I used ::
public function beforeFilter() {
$this->Auth->allow('index', 'SystemAccess');
$this->Security->blackHoleCallback = 'blackhole';
}
public function blackhole($type) {
$this->Auth->logout();
$this->Session->setFlash('Sorry a security issue has been detected, please try again or contact us for support.', 'default', array(), 'bad');
$this->redirect($this->Auth->redirect('/'));
}
Now I will add that the call the Auth logout I added to this for extra added security, as the user maybe have logged in on a system and it just not be them that is trying to do things that they should not.
Hope that helps others out!
But this is only a fix for when CakePHP is in use. I would take it that other frameworks would have their options but if your only using basic HTML? or a CMS like Drupal again there might be in built security.
Many Thanks
Glenn.
The only safe and best solution that I found for this issue is to check on the server side whether the user_id sent with the form is the same user_id logged in with or not.
Although using jquery is good idea, but, did not work with my case as am using data: $(this).serialize(),
However here's my code on the server side (Note, am using Laravel 5.4, but am sure it won't matter with your case)
if ($request->user_id != Auth::user()->id)
return json_encode("F**K YOU ! Don't Play Smart -_- !");
else
raw_material_category::create($request->all());
Hope this helped ;)
I have implemented Zend_Lucene in my first Zend Framework Project, but since I have implemented Routes the Search Results does not seem to work anymore.
In my Search Result view, I have changed the URL to the Postdetails to use the Route:
<a href="<?php echo $this->url(array('post' => $value['post_id'], 'postname' => $value['post_title']), 'postdetails', true); ?>">
Unfortunately it does not seem to work, instead it shows me
<a href="/%3C%21DOCTYPE+html+PUBLIC+.......
I normally also use
$this->escape($value['post_title'])
but again, it shows something with DOCTYPE. I don't understand enough about ZF to know what goes wrong. Can someone give me a hint? Thank you very much in advance!
Have you tried using your named route without setting the reset option to true? I think you might be contradicting your self. You are telling the url helper to use a named route at the same time telling it to use the default routes. if you haven't already try:
<a href="<?php echo $this->url(array('post' => $value['post_id'], 'postname' => $value['post_title']), 'postdetails'); ?>">
you also may need to set default values for post and postname in your route(if you haven't already)
I've written a web application using Catalyst that has a lot of forms and needs to run over https. There are no hard-coded URLs, everything uses $c->uri_for or $c->req->uri. Everything worked great in the development environment using the dev server running over http.
Today, when I went ahead and deployed the application, I noticed a problem. The way our production environment is currently setup, client browsers talk to a F5 load-balancer over HTTPS and the F5 talks to the web server on the internal network over HTTP.
[ Browser ] ---HTTPS---> [ F5 ] ---HTTP---> [ Web Server ]
Now, because the web server only gets HTTP requests, all URIs are generated starting with HTTP. This means:
<form action='[% c.uri_for('/secure/form') %]' method='post'>
becomes:
<form action='http://websitename.org/secure/form' method='post'>
and now all browsers complain you are submitting data over an insecure connection. I need that c.uri_for to begin with https.
The app needed to go live today, so I did a mass search/replace for all form actions to this:
<form action='[% c.uri_for('/secure/form') | replace('http:', 'https:'%]' method='post'>
Well, now that breaks development, so I conditionalized the form actions based on a config key:
[% IF c.config.production %]
<form action='[% c.uri_for('/secure/form') | replace ('http:', 'https:') %]' method='post'>
[% ELSE %]
<form action='[% c.uri_for('/secure/form') %]' method='post'>
[% END %]
Needless to say, this all just seems wrong on multiple levels. Anyone have a better idea? And is there a way to force $c->uri_for to generate a URI that begins with https?
Solution
If you're using Catalyst 5.80008 or later, set MyApp->config(using_frontend_proxy => 1); and simply have your proxy set the X-Forwarded-Port header. For Catalyst versions prior to 5.80008, still set using_frontend_proxy so you get the actual client_ip, but to generate the correct URIs have your web server set the environment variable HTTPS to ON
You might try this configuration option:
MyApp->config(using_frontend_proxy => 1);
It's described in Catalyst's documentation
The following works (tested):
In MyApp.pm, add the following sub:
sub secure_uri_for {
my ($self, #args) = #_;
my $u = $self->uri_for(#args);
$u->scheme('https');
return $u;
}
Now any time you want a guaranteed https, you can call $c->secure_uri_for('whatever')
I don't use Catalyst, but the docs for uri_for point to the request object's base method.
I read the source, and found that base is a read/write method. So, you should be able to squeeze $req->base('https://foo.bar.com/') into your code somewhere to get your https uris.
Update:
singingfish says that the above advice is incorrect--which wouldn't surprise me at all, it was based on a quick look at TFM. S/He also says that the scheme method should be set instead. I assume s/he is referring the the uri object's scheme method.
Further searching turned up HTTPS Tricks on the Catalyst Wiki. It shows an example of setting the scheme on the uri objects returned by the uri_for_action method. It looks like you would need to set the scheme on every uri you request, all over your code. So, I can't help but feel that the scheme method may not be the best choice.
I also found this thread on the mailing list. Setting base or setting an environment variable are both recommended methods.
This gives you several avenues of investigation. Good luck.
I recently converted a site from asp to CF. Unfortunately, alot of the old users had the "homepage" bookmarked. www.example.com/homepage.asp
Is there a sort of catch all way I could redirect any traffic from that page to the current index.cfm?
I would normally just delete those files, but the owner(s) wanted to keep it around for their own comparison reasons.
Any ideas?
Thanks
Put this in the old homepage.asp
<%# Language=VBScript %>
<%
Response.Status="301 Moved Permanently"
Response.AddHeader "Location", "/index.cfm"
%>
If you don't want run an onerous asp file at all on the new site, you can do a custom 404 on the web server. If you point the 404 page to a .cfm file, you can extract all the various features from the request by including:
<!--- parse out the text in the URL parameters into an array --->
<cfset variables.requestparams = listtoarray(cgi.query_string,'/?&')>
<!--- get rid of the first 2 items in the array since they dont represent request info --->
<cfset foo = arraydeleteat(variables.requestparams,1)>
<cfset foo = arraydeleteat(variables.requestparams,1)>
You'll be left with an array representing the parameters that were passed in the original request. You can follow up on this by doing whatever analysis you need to on the url components to map it against the analogous pages in your CF site.
I'm surprised nobody has mentioned URL Rewriting. You can use mod_rewrite on *nix/apache, or ISAPI Rewrite or Ionics ISAPI Rewrite on Windows/IIS. I prefer Ionics if I'm on IIS.
The best bet is to do either a meta refresh in the actual homepage.asp page, it is quick and dirty, but works.
A better solution would be to have the .asp page do a 301 redirect to the new homepage, that way when search engines access the page as well they know it has moved.
What I do on Linux machines when I run into something like this is to create a symbolic link (ln -s /path/to/source /path/to/target).
Not sure what the Windows equivalent would be, so going with #Patrick's answer is probably best.
EDIT - The NTFS way of making a symlink:
http://en.wikipedia.org/wiki/NTFS_symbolic_link
see also http://en.wikipedia.org/wiki/Symbolic_link