I want to add a sort of custom middleware in Traefik, where I can check user identity and after validating from the database, I want to route users to different versions of the application? Is it possible with Traefik?
For the time being, the only way to add a custom middleware to Traefik is to fork it and add your custom middleware into the source code and build it for yourself. Actually this is not too difficult but of course it comes with all the downsides of forking. There is an example here: https://github.com/negasus/traefik2-luascript. You need to edit it a bit because it is somewhat outdated but I was able to add my custom middleware by following it.
Related
I want to deploy a Nuxt application but I have a problem with Csp. I added all the Sha256 to my Csp but some lines are still stuck. I think it's the lines with :style="". What would be the solution? Is it really risky to add an "unsafe-inline"?
Everything works if I add "unsafe-inline" but I'm not sure that's great for site security.
I also specify that all my other Headers are well configured
If you add hashes for event attributes such as onclick, onerror etc, it won't work. You can make it work if the browser has implemented full support for 'unsafe-hashes', but there are likely still a lot of users who are not at that level. Otherwise you'll need to rewrite the event attributes to event listeners if you don't want to add 'unsafe-inline'.
I am learning express and the http methods, but I cannot find any documentation on it. Is /api/value just for the json data, like an address just for that data? Just any extra info on it would be appreciated. Like what exactly does it do and if there is any documentation from express about it. Or is this a global term used in urls throughout frameworks and the internet?
For example:
app.get('/api/jackets'(req, res) => {res.send('logic')})
Why do we need to add the api before jackets and what does it do?
It's not necessary, it's used only for a better understanding
The /api request is not required, but putting a prefix in front of the API requests such as:
/api
or, in some cases including a version number:
/api/v1
Allows you to use the same web server for more than one type of request because the /api prefix uniquely identifies each API request as an API request and it can easily be routed to where you handle API requests. You could have plain web page requests from a browser served by the same web server. While, you don't have to use such a prefix, using it gives you the most flexibility in how you deploy and use your server.
Similarly, putting the version in the prefix such as /api/v1 allows you to evolve your API in the future in a non-backward-compatible way by adding a new version designation without breaking prior API clients (you support both versions at the same time - at least for a transition period).
Currently I am do not have any informationabout my WebApi version in url. So all my endpoings looking like this http://mywebapi/api/getsomethig/id
I wan to have verson number in WebApi url as well but also want to keep the current alias. Is there a way I can configure my WebApi like that so it can respond with different aliaes:
http://mywebapi/api/getsomethig/id
http://mywebapi/api/v2.0/getsomethig/id
http://mywebapi/api/v2/getsomethig/id
What is the best approach of doing that?
Is there a way to remove the p_auth in the POST header, but still having it in the body? I still required the authentication check, therefore disabling it is not the option. Thanks
I know that this is an old question but there is no answer yet. You should enable friendly url mapping in Liferay. This involves creating a xml config file describing the url patterns and routes. You can find some information on it here.
Once it is enabled you can specify the p_auth parameter to be hidden from the url.
I'm a new to RESTful API's and sort of developing my first one at the moment for a mobile application to be followed. I have a question regarding API versions and how to manage/tackle them.
At this moment, my API 'version' is a directory named v<version_name> in which my API class resides. In that directory, I have resources that the API and REST client needs in another directory named include. So the structure is as follows: example.com/api/v0.2/method_name/ and on .htaccess, I'm making sure that everything that follows the API version (hardcoded in the .htaccess file, is saved in a query string parameter).
I'm not sure if it is the right approach for a live application as it requires manually changing the URL endpoints at clients' ends, too. So my questions are:
Is this the right approach to API versioning?
If it is and I keep it, how do I deal with outdated URL's. Say for instance the app is live and I update the API to v0.3 but the client who have the app installed would be accessing v0.2 and getting a 404 response code back?
Is there more elegant solution out there? It must be.
Edit: there are some resources that reside outside of the api folder itself, in the root include folder so to speak.
Edit 2: My API is targeted to be consumed by mobile applications and is not publicly consumable.
While I think these questions are primarily opinion-based, I will have a go...
I think it is a valid approach, and I've seen others use it,
including Microsoft.
When it is necessary to outdate an API, you could give a 404
back with an explanation that the new API is at the new address.
HOWEVER it is usually a bad idea to just retire an API version; you
would at least have to give client developers enough time to switch
to the new API before retiring the old, if at all.
A more elegant solution would be to just keep the API at one
address, and update that as necessary, and add to it rather than
replace whenever possible. Keep supporting outdated functions for as
long as possible and have open communication to client developers
about when a certain method will no longer work.
Just my opinion, do with it what you will...