using the chrome.declarativeWebRequest, it is possible to execute actions if some conditions apply. The only available Condition is an Instance of declarativeWebRequest.RequestMatcher which is useful to test if the url has some features. I am searching for a way to test if an url does not have some features For instance:
chrome.declarativeWebRequest.onRequest.addRules([
{
conditions: [
new chrome.declarativeWebRequest.RequestMatcher({
url: { hostSuffix: 'google.com' } })
],
actions: [
new chrome.declarativeWebRequest.CancelRequest()
]
}
]);
Will block all Requests to the host google.com. But I am interested in a rule that does the opposite, block everything but google.com.
According to documentation, you can use the rules' priorities to achieve your goal: create one rule to cancel all requests and another rule, with higher priority, to ignore the first rule if the host is google.com.
Related
In background.js I am using rules but I am also using regex so many times. I have declarativeContent.ShowPageAction based on these rules.
new chrome.declarativeContent.PageStateMatcher({pageUrl: { urlMatches: 'https?:\/\/([a-z0-9]+[.])*microsoft.com'},}),
new chrome.declarativeContent.PageStateMatcher({pageUrl: { urlMatches: 'https?:\/\/([a-z0-9]+[.])*google.com'},}),
new chrome.declarativeContent.PageStateMatcher({pageUrl: { urlMatches: 'https?:\/\/([a-z0-9]+[.])*amazon.com'},}),
Is there a way to use regex only once and use it as in javascript
myRegexInstance.test(collectionOfURLs);
Don't use regexp. They're slow and you're duplicating the job already performed by the API: it already separated the URL into parts which you can test separately.
Use hostSuffix:
[
'.microsoft.com',
'.google.com',
'.amazon.com',
].map(s => new chrome.declarativeContent.PageStateMatcher({pageUrl: {hostSuffix: s}}))
The leading dot will match both *://google.com/ and any subdomain e.g. *://www.google.com/
I have a hiera construct that provides certificate names for the apache module that looks like this:
profiles::web_host::vhosts::params:
'subdomain.domain.de'
serverName: 'subomain.domain.de'
certificateName: 'wildcard.domain.de'
'subdomain2.domain.de'
serverName: 'subomain2.domain.de'
certificateName: 'wildcard.domain.de'
In my webserver profile there's a lookup for the params
$vhostParams = lookup("profiles::web_host::vhosts::params")
And then I'm looping over the params:
$vhostParams.each |$key, $vhOptions| {
if $vhOptions['certificateName'] {
$certificateName = $vhOptions['certificateName']
}
}
Here's the problem: As soon as you use a wildcard certificate (as intended) for multiple subdomains there's a duplicate definition for the variable $certificateName.
I experimented with .unique applied to the variable as well as during the lookup $vhostParamsMerged1 = lookup('profiles::web_host::vhosts::params',Hash,'uniq',undef) without much success.
I'd be glad if you can help.
Kind regards,
Thomas
Thanks all for looking into this :)
I was ill for a while so sorry for my late feedback.
You're right I should've postet the whole profile but it contains some hostnames I dont want to go public.
I solved it by workaround.
The same certificate is now put into many files based on the vhost it is used by.
If anyone has a solution how to use the puppet function .each looping through hiera, create an array/hash and use only unique values - I'm still interested.
For everyone who has a similar problem:
Like always - you just have to make all your resources unique.
For my case the code now looks a like this (each time for ssl certificate and key):
$vhostParams.each |$key, $vhOptions| {
[...]
#
# Certificate(s)
#
file { "Web Server vhost $defaultSslZone SSL Key for ${key}":
# notifies the apache service to do a reload
notify => Class['apache::service'],
[...]
apache::vhost { "${key}":
ssl => true,
ssl_cert => "${cCERTS_BASE_DIR}/${sslZone}-${key}_cert.pem",
ssl_key
}
=> "${cCERTS_BASE_DIR}/${sslZone}-${key}_key.pem",
I've been trying to create a second option of url rewrites to a product inside prestashop. In the standard Prestashop installation at the SEO & URL's section i've got the following products url build-up:
{category:/}{id}-{rewrite}-{ean13}.html
This creates the following products url:
https://www.example.com/{category-name}/{product-id}/{product-name}/{ean13}.html
What i would like to add is an option for various reasons to acces a products page through the following url build up:
ean/{ean13}.html
The result url would be something like the following example:
https://www.example.com/ean13/{ean13}.html
NOTE, ID is a standard required field of the url build up, this means that i can't use: "Just ajust the url build up" as an answer.
Is there a module, addon, or piece of code out there that would be able to generate these kind of structures?
I did find some "Remove ID's from pretty url's" modules but that doesn't give me the result i'm searching for. Only partially since it only removes the ID's.
It wouldn't be a problem if it's a redirect to the standard url build up as mentioned in the first {code} segment. I know i could write rewrite rules in my .htacces file but to do this for every product would be a lot of work so i was wondering if there is a more easy way of achieving this.
As always thanks in advance!
If you're fine with redirect to standard URL then the solution is quite easy with a module.
Create a module that uses hook moduleRoutes and configure a friendly URL to use module controller
Create a module front controller
Run a db query in your custom controller to check if a product with requested EAN exists
Redirect to product page if product exists, otherwise to 404 page or something
I assume you know how to write modules and controllers, so I won't write entire code just the relevant bits.
Hook moduleRoutes in module class.
In this hook you can configure a friendly URL for your custom controller.
public function hookModuleRoutes()
{
return [
'mymodulename-mycontrollername-root' => [
'rule' => 'ean13/{:ean13}.html',
'controller' => 'mycontrollername',
'keywords' => [
'ean13' => ['regexp' => '[0-9]+', 'param' => 'ean13']
],
'params' => [
'fc' => 'module',
'module' => 'mymodulename'
]
]
];
}
So visiting https://www.example.com/ean13/12345.html will run your module controller and a GET variable ean13 will have a value of 12345.
Then create mycontrollername module controller where you can use postProcess() method to check if EAN exists.
public function postProcess()
{
$query = new DbQuery();
$query->select('id_product')
->from('product_attribute', 'pa')
->where('pa.ean13 = ' . (int)Tools::getValue('ean13'))
$productId = Db::getInstance(_PS_USE_SQL_SLAVE_)->getValue($query);
if ($productId) {
Tools::redirect($this->context->link->getProductLink($productId));
}
Tools::redirect('pagenotfound');
}
In query we check in product_attribute table as product combinations can have their own EAN13 and you also want those EAN13's to redirect to product page.
The basics of this answer is most commonly used to replace core product search controller with a custom and SEO friendly one.
I am new to node.js and have my first node.js Restful API built in hapi.js framework. All the services do is basically doing database query. An example of the services is like this:
let myservice = {
method: "POST",
path: "/updateRule",
config: {
handler: (request, reply) => {
updateRule(request.payload)
.then((result) => {
reply(successResponse(request, result));
})
.catch((err) => reply(failResponse(request, err)).code(500));
},
validate: {
payload: {
ruleId: joi.number().required(),
ruleName: joi.string().required(),
ruleDesc: joi.string().required()
}
},
auth: "jwt",
tags: ["api", "a3i"]
},
}
updateRule(input): Promise<any> {
return new Promise((resolve, reject) => {
let query = `select a3i.update_rule(p_rul_id := ${input.ruleId}, p_rul_name := '${input.ruleName}', p_rul_desc := '${input.ruleDesc}')`;
postgresQuery(lbPostgres, query, (data, commit, rollback) => {
try {
let count = data.rows[0].update_rule.count;
if (count === 1) {
let ruleId = data.rows[0].update_rule.result[0];
let payload: SuccessPayload = {
type: "string",
content: `Rule ${ruleId} has been updated`
};
commit();
resolve(payload);
} else {
let thisErr = new Error("No rule can be found.");
thisErr.name = "4003";
throw thisErr;
}
}
catch (err) {
rollback();
if (err.name === "4003") {
reject(detailError(4003, err.message));
} else {
reject(detailError(4001, err.message));
}
}
}, reject);
});
}
As you can see, when the service is called, it evokes a database call (query) and updates specified row in database table. Similarly, I have other services named createRule/deleteRule creating/deleting records in database table. In my opinion, the difference between the services is doing different database query. I read this post PUT vs. POST in REST but couldn't see any difference of POST and PUT in my case.
Here are my questions:
What HTTP method should I used in this case?
Most of Restful API examples (for example https://www.codementor.io/olatundegaruba/nodejs-restful-apis-in-10-minutes-q0sgsfhbd) use the same URL with different HTTP methods to do different operations on same "resource", which in my opinion is usually a database table. What's the benefit of this architecture compared with my practice in which one URL only has one HTTP method and only do one type of operation?
I know this question does not refer to a problem and is not specific. Some people may give it a down-vote. But as a beginner I really want to know what's a typical Restful API and make sure my API is "best practice". Please help!
If the resource already exists and thus you have a specific URI to that exact resource and you want to update it, then use PUT.
If the resource does not exist yet and you want to create it and you will let the server pick the URI that represents that new resource, then use POST and the POST URI will be a generic "create new resource" URI, not a URI to a specific resource and it will create the URI that represents that resource.
You can also use PUT to create a new resource if the caller is going to create the resource URI that represents the new resource. In that case, you would just PUT to that new resource and, if a resource with that URI already exists, it would be updated, if not, it would be created.
You do not have to support both. You can decide to make your api work in a way that you just use one or the other.
In your specific case, an update of a specific row in your database that already exists would pretty much always be a PUT because it already exists so you're doing a PUT to a specific URI that represents that row.
What's the benefit of this architecture compared with my practice in which one URL only has one HTTP method and only do one type of operation?
It's really up to you how you want to present your API. The general concept behind REST is that you have several components:
resource identifier
data
method
In some cases, the method can be subsumed by GET, PUT, POST or DELETE so you just need the resource identifier, data and GET, PUT, POST or DELETE.
In other cases or other designs, the method is more detailed than can be expressed in just a PUT or POST, so you have a method actually in the URL in which case, you may not need the distinction between PUT and POST as much.
For example, an action might be "buy". While you could capture that in a POST where the method is implied by the rest of the URL, you may want to actually POST to a URL that has a method in it: /buy for clarity and then you may use that same endpoint prefix with other methods such as /addToCart, etc... It really depends upon what the objects are in your REST design and what operations you want to surface on them. Sometimes, the objects lends themselves to just GET, PUT, POST and DELETE and sometimes, you want more info in the URL as to the specific operation to be carried out on that resource.
If you want to be Rest compliant, you can just use Post and Get.
If you want to be Restfull, you need to base your method on the CRUD
Create -> Post
Read -> Get
Update -> Put or Patch
Delete -> Delete
About building a full API, using method on the same URL could be easier to build / understand. All queries about your user will be on the user url and not user/get, user/add, user/update ... It let you have the same functionality, without too much different URL.
When you build an API, you will want to have some logs, for stats analysis and other stuff. This way, if you split with your method, you can just have a filter to logs how many Post requests, or Get requests.
In fact, you could build an API only with Get requests too. But spliting with methods and URL is the best way to avoid complexes URL (or URL with too much action name) and to have an easiest way to log every requests going through your API
- List item
Level 1 is Rest
Level 2 is Restfull
Level 3 is Hateoas
You should find more informations inside some books or articles written by Martin Fowler
What I usually do is use "POST" for creating a new resource, and use "PUT" for updating an already existing resource.
For your second question, yes most API's use the same URL to do different things on the same resource. That could be because of security where you don't want to expose what you are doing in your URL's (/delete for example). Also, many frameworks generate an auto URL for a resource (Object Class), that is then differentiated on the request method. People just don't tend to use custom URL's for those.
I am using the add_rewrite_rule() function to modify my URL structure.
I'm wanting to use add_rewrite_rule to add a custom rule but these rules only get added in when other than default settings are selected in my permalink settings area.
i.e. in the settings there are following options:
- Default http://localhost/wordpress/?p=123
- Day and name http://localhost/wordpress/2014/08/14/sample-post/
- Month and name http://localhost/wordpress/2014/08/sample-post/
- Numeric http://localhost/wordpress/archives/123
- Post name http://localhost/wordpress/sample-post/
- Custom Structure http://localhost/wordpress
So, when I select other then 'Default', my add_rewrite_rule() function works, but while selecting 'Default', the function doesn't seem to be work. So please suggest me how to work the function in any condition. Any help would be Appriciated.
Update:
I think the problem lies here:
When I use this, while selecting 'Default':
get_option('permalink_structure');
I got nothing.
While in the other cases, there are some values like:
/%postname%/
/archives/%post_id%
/%year%/%monthnum%/%postname%/
The Default permalinks, or so called "Ugly" permalinks, are not adding anything to the .htaccess file, so the Apache rewrite engine is not enabled. Without the rewrite engine, no rewrites can be done. So the short answer is that rewrites are not possible with Default permalinks.
I can recommend you to use rewrites along with query vars. When adding a rewrite rule, pass your custom data to a query var, and build the functionality around that query var. This way your functionality will work in all situations and with all permalink types.
So for example if you have the following rule:
add_rewrite_rule('^sometest/([^/]*)/?','index.php?custom_query_var=$matches[1]', 'top');
and you have the custom_query_var added as a query var by using the following code:
function add_query_vars_filter( $vars ){
$vars[] = "custom_query_var";
return $vars;
}
add_filter( 'query_vars', 'add_query_vars_filter' );
then when Default permalinks are selected, the following URL would work for you:
http://yoursite.com/index.php?custom_query_var=abc
and if "Pretty" permalinks are selected, the URL rewriting would work and your URL would look the following way:
http://yoursite.com/sometest/abc/
which is basically the best that can be achieved with rewrites.
I agree with #Martin. Here's a resource that will help https://core.trac.wordpress.org/ticket/15235
use this:
function my_add_query_vars( $qvars ) {
$qvars[] = 'business-coaching';
$qvars[] = 'country';
$qvars[] = 'territory';
$qvars[] = 'region';
return $qvars;
}
add_action('query_vars', 'my_add_query_vars');
//Write the rule
function add_analytic_rewrite_rule()
{
// Regex:The regex to match the incoming URL is:business-coaching(/([^/]+))?(/([^/]+))?(/([^/]+))?/?
// Redirect Rule :The resulting internal URL: `index.php` because we still use WordPress
// `pagename` or page_id=45 because we use this WordPress page
// `country` : we will assign the first captured regex part to this variable
// `territory` we will assign the second captured regex part to this variable
// `region` we will assign the third captured regex part to this variable
add_rewrite_rule('business-coaching(/([^/]+))?(/([^/]+))?(/([^/]+))?/?','index.php?page_id=45&country=$matches[2]&territory=$matches[`enter code `enter code here`here`4]®ion=$matches[6]','top');//superfinal
}
add_action('init', 'add_analytic_rewrite_rule');