We have a cakephp app running on 2.0 and we seem to be having some encoding issues with Firefox.
The URL we are accessing is /newcms/core/users/index/conditions[User][group_id]:6 to apply a filter in out cms system.
In everything but FireFox we get the following on the request object
[params] => Array
(
[plugin] => core
[controller] => users
[action] => newcms_index
[named] => Array
(
[conditions] => Array
(
[User] => Array
(
[group_id] => 6
)
)
)
[pass] => Array
(
)
[prefix] => newcms
)
Which is correct and everything works fine, if we goto the same URL in FireFox we get
[params] => Array
(
[plugin] => core
[controller] => users
[action] => newcms_index
[named] => Array
(
[conditions%5BUser%5D%5Bgroup_id%5D] => 6
)
[pass] => Array
(
)
[prefix] => newcms
)
I have tried URL encoding the named condition value but with no luck..
Any suggestions?
It's probably not a great idea to be using brackets and an array structure in your URL.
Why not just use something like this?:
/newcms/core/users/index/user_group:6
Then process the data in the controller.
Well after a bit of digging and playing around the latest version of cake in GitHub has fixed this FF issue (https://github.com/cakephp/cakephp/commit/e6905b44c3d4512b6989c59a1489bc983d88bcdc).
There is nothing incorrect about passing square brackets in the URI it was just an issue with the way FF encoded them differently than the other browsers.
Related
I am struggling a bit with localization in Laravel 5.3 (with php 7). The default localizaiton file format in Laravel 5.3 is using brackets, as in this example:
return [
'footer.contact.email' => 'Email:',
]
That's what I have been using in my app and it's working fine. But now I am trying to work with some packages to help with translations, for example:
https://github.com/potsky/laravel-localization-helpers
https://github.com/barryvdh/laravel-translation-manager
But both of those generate localization files in the "old" laravel 4.x array format. For example
return array(
'footer' => array(
'contact' => array(
'email' => 'Email:',
),
),
);
As I understand it I should have no issue with this localization file format in my laravel 5.3 app, however it's always throwing an exception:
[2016-12-02 13:26:01] local.ERROR: ErrorException: htmlspecialchars() expects parameter 1 to be string, array given in C:\100_source_code\consulting_platform_laravel\maingig\vendor\laravel\framework\src\Illuminate\Support\helpers.php:519
Stack trace:
#0 C:\100_source_code\consulting_platform_laravel\maingig\vendor\sentry\sentry\lib\Raven\Breadcrumbs\ErrorHandler.php(36): Illuminate\Foundation\Bootstrap\HandleExceptions->handleError(2, 'htmlspecialchar...', 'C:\\100_source_c...', 519, Array)
I really cant understand why this format is not working with my app. I bet it is something trivial that I am missing, but any help would be very welcome!
Thanks,
Christian
After a few extra hours of stepping through the code I found the source of the problem.
For example, I got these in my original lang file:
'footer.subscribe' => 'SUBSCRIBE TO OUR NEWSLETTER',
'footer.subscribe.intro' => 'Be the first to know about our latest news...',
'footer.subscribe.privacy' => 'Privacy Policy',
'footer.subscribe.tos' => 'Terms of Service',
'footer.subscribe.tac' => 'Terms and Conditions',
As I tried to use both of the packages mentioned in my original question they produced the following output:
'footer' =>
array (
'subscribe' =>
array (
'intro' => 'TODO: intro',
'privacy' => 'TODO: privacy',
'tos' => 'TODO: tos',
'tac' => 'TODO: tac',
),
),
As you can see the generated file dropped the value for the text footer.subscribe and only kept the child element, intro, privacy, tos and tas in this case. Therefore a request for trans('footer.subscribe') returns an array and not the text.
Now that I know this I will change the format of my original translation file!
c.
I'm implementing a (rather complex) RESTful API.
I use Lighttpd as web server with two FastCGI backends:
a generic PHP handler for the bulk of requests
a specialized C++ handler for several other requests
my current fastcgi.conf looks like (simplified):
server.modules += ( "mod_fastcgi" )
fastcgi.server = ( ".php" => ( "PHP" => (
"bin-path" => "/usr/bin/php-cgi",
"socket" => "/tmp/php.socket",
"check-local" => "disable",
"bin-environment" => ( "PHP_FCGI_CHILDREN" => "0", "PHP_FCGI_MAX_REQUESTS" => "500" ),
"bin-copy-environment" => ( "PATH", "SHELL", "USER" ),
"max-procs" => 1,
"broken-scriptfilename" => "enable"
)),
"/api/groupA" => ( "Server" => (
"socket" => "/tmp/fcgi-C.socket",
"check-local" => "disable",
)),
"/api/groupB" => ( "Server" => (
"socket" => "/tmp/fcgi-C.socket",
"check-local" => "disable",
)),
"/api/groupC" => ( "Server" => (
"socket" => "/tmp/fcgi-C.socket",
"check-local" => "disable",
)),
"/api/" => ( "PHP" => (
"bin-path" => "/usr/bin/php-cgi",
"socket" => "/tmp/php-P.socket",
"check-local" => "disable",
"bin-environment" => ( "PHP_FCGI_CHILDREN" => "0", "PHP_FCGI_MAX_REQUESTS" => "500" ),
"bin-copy-environment" => ( "PATH", "SHELL", "USER" ),
"max-procs" => 1,
"broken-scriptfilename" => "enable"
))
)
This means I filter prefixes intended for C++ handling and default the rest to PHP.
PHP part works as expected.
Problem here is C++ handler receives a truncated request path with "/group(A|B|C)" stripped away (everybody gets the path without the leading "/api", but that's OK).
How can I restore the full path?
Alternatively: Is there (or can I produce) some variable/header/whatever I can test in C++ to get the "missing part"?
I am fully prepared to cope with redundant information (e.g.: path restored to the full "/api/..."), but I need the information that has been dropped.
Only thing that comes to mind would be to differentiate the sockets and to have a filter restoring the information based on actual incoming socket but that seems overcomplex and very brittle; I'm hoping for a simpler solution, possibly involving URL-rewrite (I'm not familiar with Lighttpd configuration intricacies, I'm more of a C++/PHP/java coder, so I hope I overlooked something obvious ;) )
The original request from the client can be found in REQUEST_URI.
mod_fastcgi also has config options to allow a limited set of URL mangling for broken PHP.
https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModFastCGI
I'm trying to perform transaction using Sagepay Server API. I've properly setup by simulator vendor account and also added the IP address. Still im getting the following error
Sage Pay returned an MALFORMED status. The POST was Malformed because "Simulator cannot find your vendor name. Ensure you have have supplied a Vendor field with your Vendor name assigned to it."
Here is my POST request data
[VPSProtocol] => 2.23
[TxType] => PAYMENT
[Currency] => GBP
[Vendor] => curiouslabx
[NotificationUrl] => http://localhost:8080/numberplate/sagepay_notification
[Description] => Purchase of number plate AU59STG
[AllowGiftAid] => 0
[ApplyAVSCV2] => 0
[Apply3DSecure] => 0
[Profile] => NORMAL
[AccountType] => E
[Amount] => 700.00
[success_url] => http://localhost:8080/numberplate/payment/payment_status/success/
[failure_url] => http://localhost:8080/numberplate/payment/payment_status/failure/
[BillingFirstnames] => test
[BillingSurname] => test
[BillingAddress1] => test
[BillingAddress2] => test
[BillingCity] => testtest
[BillingPostCode] => test
[BillingCountry] => test
[BillingState] => test
[BillingPhone] => test
[DeliveryFirstnames] => test
[DeliverySurname] => test
[DeliveryAddress1] => test
[DeliveryAddress2] => test
[DeliveryCity] => testtest
[DeliveryPostCode] => test
[DeliveryCountry] => test
[DeliveryState] => test
[DeliveryPhone] => test
[VendorTxCode] => 14-04-30-20-10-53-572086512
I'm using sagepay server library for codeigniter https://github.com/ollierattue/codeigniter-sagepay-server/
If you are using the Simulator, things are in a bad way anyway. It does not support protocol 3.00 - your will need to integrate at this level, or your integration will cease to function on 31/7/15
EC2 gives instances a new IP address when they're stopped then restarted, so I need to be able to automatically manage a route53 record set so that I can access things consistently. Sadly the documentation for the route53 portion of the sdk is not nearly as robust as it is for ec2 (understandably) and so I'm a bit stuck. From what I've seen so far, it seems like change_resource_record_sets (link) is the way to go, but I'm confused as to what needs go into :chages since it mentions a Change object but fails to provide a link to a description of said object.
Here's what my code currently looks like for a creation:
r53.client.change_resource_record_sets(:hosted_zone_id => 'MY_ID', :change_batch => {
:changes => 'I DONT KNOW WHAT GOES HERE',
:action => 'CREATE',
:resource_record_set => {
:name => #instance.instance_name,
:type => 'CNAME',
:ttl => 330,
:value => #instance.ip_address
}})
EDIT: Okay, since I haven't had any help either here or on the official forums I've been messing around with it myself. So it turns out that the documentation is just plain awful. All of the values are stored in a Change object, and not given there. So it actually looks more like this:
some_change = AWS::Route53::CreateRequest.new(#instance.instance_name,
'CNAME',
:ttl => 330,
:resource_records => [
{:value => #instance.ip_address}
])
r53.client.change_resource_record_sets(:hosted_zone_id => 'MY_ZONE', :change_batch => {
:changes => [some_change],
})
The documentation is pretty poor, though it does contain a few examples. I initially had the impression that it was necessary to create requests (and use the client object) per your solution, but there are alternatives.
An example of creating a record can be found in the ResourceRecordSetCollection reference, but it's only a little more concise than your answer:
rrsets = AWS::Route53::HostedZone.new(hosted_zone_id).rrsets
rrset = rrsets.create('foo.example.com.', 'A', :ttl => 300, :resource_records => [{:value => '127.0.0.1'}])
I wanted to update an existing record, and didn't have the hosted_zone_id to hand. It took far too long to figure out how best to do this, so I'm offering the following example in the hope it saves someone else some time:
r53 = AWS::Route53.new
domain = "example.com."
fqdn = "host." + domain
zone = r53.hosted_zones.select { |z| z.name == domain }.first
rrset = zone.rrsets[fqdn, 'A']
rrset.resource_records = [ { :value => "1.2.3.4" } ]
rrset.update
Note that that assumes you only have a single zone with that name in Route53.
The method that zts posted seems to be a much better way of updating records. However, if you're updating an alias record then you have to use DeleteRequest/CreateRequest as the alias_target instance attribute on ResourceRecordSet seems to be readonly, even though the docs don't list it as so.
Here's one way to do it. Note that the hosted zone id for the alias target (region in the code below) should not be a personal zone ID, it is actually an encrypted region ID. This doesn't seem to be documented anywhere, and the only reference for these IDs that I could find was in the source of the fog gem.
Edit: This has now moved to a separate module called fog-aws and is more up to date.
{
"ap-northeast-1" => "Z2YN17T5R711GT",
"ap-southeast-1" => "Z1WI8VXHPB1R38",
"ap-southeast-2" => "Z2999QAZ9SRTIC",
"eu-west-1" => "Z3NF1Z3NOM5OY2",
"eu-central-1" => "Z215JYRZR1TBD5",
"sa-east-1" => "Z2ES78Y61JGQKS",
"us-east-1" => "Z3DZXE0Q79N41H",
"us-west-1" => "Z1M58G0W56PQJA",
"us-west-2" => "Z33MTJ483KN6FU",
}
And the code:
change_request = {
hosted_zone_id: zone.id,
change_batch: { changes: [] }
}
alias_target = {
hosted_zone_id: region,
evaluate_target_health: false
}
# Delete the record if it already exists
if rrset.exists?
alias_target[:dns_name] = rrset.alias_target[:dns_name]
delete_request = AWS::Route53::DeleteRequest.new(fqdn, 'A', alias_target: alias_target)
change_request[:change_batch][:changes][0] = delete_request
r53.client.change_resource_record_sets(change_request)
end
# Create the new record
alias_target[:dns_name] = new_alias
create_request = AWS::Route53::CreateRequest.new(fqdn, 'A', alias_target: alias_target)
change_request[:change_batch][:changes][0] = create_request
r53.client.change_resource_record_sets(change_request)
I hacked it until it worked, and here are my results:
Don't look at the ruby route53 documentation for anything but method/object/attribute names. It is misleading, if not outright wrong. Instead, check out the rest documentation since the client just builds up a standard xml request anyway. My example of creating a simple record is as follows:
some_change = AWS::Route53::CreateRequest.new("foo.bar.com",
'CNAME', # the type of the resource record set
:ttl => 330, # The cache time to live for the current resource record set
:resource_records => [
{:value => "0.0.0.0"} # dependent on type
])
r53.client.change_resource_record_sets(:hosted_zone_id => 'MY_ZONE', :change_batch => {
:changes => [some_change],
})
I initially worked with what #slippery John did, but that proved problematic for spot instances that reclaim certain dns names often.
I found a solution I think is better, almost I identical to his:
some_change = AWS::Route53::ChangeRequest.new("UPSERT","foo.bar.com",
'CNAME', # the type of the resource record set
:ttl => 330, # The cache time to live for the current resource record set
:resource_records => [
{:value => "0.0.0.0"} # dependent on type
])
r53.client.change_resource_record_sets(:hosted_zone_id => 'MY_ZONE', :change_batch => {
:changes => [some_change],
})
it is intentionally copied from his solution with a slight modification.
For aws-sdk v2 it is like this:
[72] pry(main)> r53 = Aws::Route53::Client.new
[73] pry(main)> change
=> {:action=>"UPSERT",
:resource_record_set=>
{:name=>"myhost.example.com",
:resource_records=>[{:value=>"192.0.2.44"}],
:ttl=>60,
:type=>"A"}}
[44] pry(main)> res = r53.change_resource_record_sets(hosted_zone_id: my_zone_id, change_batch: {changes: [change]})
=> #<struct Aws::Route53::Types::ChangeResourceRecordSetsResponse
change_info=
#<struct Aws::Route53::Types::ChangeInfo
id="/change/C02195391TWJO1GT9KVRV",
status="PENDING",
submitted_at=2020-11-03 21:39:09.41 UTC,
comment=nil>>
For more info see https://docs.aws.amazon.com/sdk-for-ruby/v2/api/Aws/Route53/Client.html#change_resource_record_sets-instance_method
Within the admin section when clicking to view an order we're getting the following error:
There has been an error processing your request
Invalid method Mage_Adminhtml_Block_Sales_Order_View_Tab_History::isCustomerNotificationNotApplicable(Array
(
[0] => Array
(
[title] => Pending
[notified] => 0
[comment] =>
[created_at] => Zend_Date Object
(
[_locale:Zend_Date:private] => en_GB
[_fractional:Zend_Date:private] => 0
[_precision:Zend_Date:private] => 3
[_unixTimestamp:Zend_Date_DateObject:private] => 1321280177
[_timezone:Zend_Date_DateObject:private] => Europe/London
[_offset:Zend_Date_DateObject:private] => -3600
[_syncronised:Zend_Date_DateObject:private] => 0
[_dst:protected] => 1
)
)
)
)
To me this looks like the default exception of Varien_Object::__call(), which is raised whenever you try to call an unknown method of an Varien_Object instance.
Either you completely missed to define an isCustomerNotificationNotApplicable method in the appropriate class, or the spellings of the defined and the called method do mismatch.
To identify the class causing the exception, I'd append the output of mageDebugBacktrace() in the throw instruction of Varien_Object::__call().
If you get no backtrace output, the exception is probably thrown in a class extending Varien_Object and overriding the __call() method. In that case scan your code for function __call( matches and append the mageDebugBacktrace() output in the found method.
In the end we copied in fresh code files from 1.6.1 and copied them into our path. It all seemed to work fine then.