I am building a jsonapi for my website, and while looking at various frontend components I came across
https://github.com/dixieio/redux-json-api/tree/master/docs
Which seems to resolve the endpoint URL directly from the resource type
It is part of the spec/recommendations to have the endpoint resolved exactl by the resource type ? I remember reading comment explaining there isn't an actual type naming convention.
My API has several endpoints for the registration of different types of user
/registration/admin
/registration/customer
etc.
Those endpoint have different business logic associated, but they all return a user type object.
Is this a bad design to have several endpoints returning the same resource type ?
Should I make changes in my code to introduce additional type like registration/user ?
Or should I submit a patch to the library so it accepts custom endpoint URLs ?
I can't address specifically the framework you're using, but you have complete freedom to choose what your HTTP resources represent. If, for example, customers can be corporate and have associated invoices and sales history, but admins are only ever individuals and cannot transact, you could make a strong case for keeping the resources seperate.
One thing you should try to avoid is allowing limitations of software dictate your URI structure. If I were creating this API, and had decided that customers and admins were different types of object, I would have the registration form resources live at /admins/new and /customers/new which would make POST requests to the collection resources at /admins and /customers. I would not have a /registration* at all.
To address your invividual questions:
I don't understand what you mean by ‘returning a resource type’ — are you talking about the representations returned in the responses, or how the back-end functions are creating and returning instances of a class?
I would not add an additional super-type for all kinds of user. Either have one collection per type, or one type for all.
If after considering all of the above and choosing URIs you want, your software cannot handle the structure you have chosen, there are three options:
i) choose more capable software
ii) create a mapping between the incoming URI and the URI handed to your software. Apache mod_rewrite can do this for you
iii) as you suggest, make the software you are already using more capable
Choose the easiest option.
Related
As you know Salesforce is enforcing Enhanced Domains. I found from Salesforce help that:
Custom components in your org must be evaluated in order to check
whether they use domain name/static URLs
Some embedded content stored in Salesforce might no longer appear
Third-party applications can lose access to your data
Single sign-on integrations can fail
However, I'm struggling with finding out which particular Salesforce elements/configurations should be checked in order to detect potential gaps? Do you know which areas exactly can be affected and shall be evaluated (like Apex Codes, Email Templates and so on)? Is there any guide on that?
Your biggest concern should be inbound integrations. Things that log in over REST/SOAP API, get response with session id back, ignore the "url to use for all subsequent requests" and just use hardcoded url, whether it's prod or sandbox.
Look at this guy, he's victim of either enhanced domain or "disable api versions < 30" thing: The requested resource no longer exists with rest PHP. Look at these guys, they had hardcoded url: how to solve python code error (TooManyRedirects: Exceeded 30 redirects), Salesforce API via postman error INVALID_SESSION_ID.
As for stuff inside Salesforce itself - best would be to download whole project with sfdx and run a text search for your domain name (and site/community name if you have these). Email templates that use merge fields for forgot password etc should be fine, merge fields with record link should be fine... But if you manually craft email body in apex - might be a problem. A lot depends how creative the developer was. If you find getsalesforcebaseurl().toexternalform() it should still work. If it's hardcoded / read from custom setting / custom label / custom metadata it might be more fun.
If you have external apps that display pieces of salesforce (embedded live chat? some iframe with FAQ? CMS Connect) - the domain change might mean they need to be updated, both in terms of updating url and changing security rules (CSP for example)
So currently in the project we have a collection of documents that don't require authentication to be read. They are write/update protected, but everyone can read.
What we are trying to prevent is that someone looks at the firebase endpoints and somehow manages to scrape the entire collection in json format (if this is even possible). The data is public, but I want it only to be accessible from our website.
One of the solutions we could think of was SSR (we are already using Next.js), but implementing SSR just for this reason doesn't seem very enticing.
Any suggestions would be appreciated.
EDIT:
Let me rephrase a little bit.
From what you see in the network tab, is it possible to forge/create a request to Firestore and get the entire collection instead of just the 1 document that was intended?
The best solution in your case is SSR. I know, it could sound as not enticing, but well, let's reason on when we should use SSR, then. In your use case, there is an important requirement: security. I think this is already a strong enough reason to justify the usage of SSR.
Also, creating an ad hoc service account for the next.js app, and securing the data with custom rules that allow the read of your data only to that service account, would only improve the overall security level.
Last: reading the data server side should make your site work a little faster, even if it would be difficult to notice, because we are talking about milliseconds. Notice that your page, as it is now, will need to be loaded, before the request to Firebase could be sent. This is adding a small delay. If the data is loaded server side, the delay is not added.
is it possible to forge/create a request to Firestore and get the entire collection instead of just the 1 document that was intended?
If you want to limit what people can request from a collection, you're looking for security rules. The most common model there is some form of ownership-based access control or role-based access control, but both of those require some way of identifying the user. This could be anonymously (so without them entering credentials), but it'd still be a form of auth.
If you don't want to do that, you can still control how much data can be gotten through the API in one go. For example, if you in the security rules allow get but not list, the user can only request a document once they know its ID. Even if you allow list, you can control in rules what queries are allowed.
I think one approach could be writing a Cloud Function that retrieves this public data using the admin SDK. Then, you could set a rule that nobody can read those documents. This means that only your Cloud Function with the admin SDK will have access to those documents.
Finally, you could set up AppCheck for that specific Cloud Function, this way, you ensure that the request is coming from your client app only.
https://firebase.google.com/docs/app-check
Titlte says it all I think.
I have encountered both and don't know which one I should use between $_SESSION['Auth'] and $this->Authentication->getIdentity(). Is one safer than the other ?
Thank you,
Simon
With CakePHP you should always use the abstracted APIs to access any superglobal data like $_POST, $_COOKIE, $_SESSION, etc..
This is advised for a multitude of reasons that depend on the specific situation, but generally it kinda touches the principle of dependency inversion, and decoupling in general, eg. your code should depend on abstractions, not concretes, then for example implementations can change without breaking your application. And while the session object, the request object, or the authentication component aren't interfaces, they still abstract the access to the underlying data (the concrete so to speak).
Something where the need for this would apply generally, would be testing, except for the CakePHP session object, which must write the data to the $_SESSION superglobal internally, other superglobals like $_GET, $_POST, $_COOKIE, etc. are not being populated if you use the API provided by CakePHP, instead the data is written into the request object, which exposes the data via its own API. So if you were for example to access $_POST directly in your code, and then pass POST data in a test like $this->post('/url', $postData), your code wouldn't see the data, as it would directly land in the request object instead of the $_POST superglobal.
As far as the authentication example specifically goes, the authentication middleware could have obtained the identity with data from who knows where, the session, cookies, tokens, etc., and likewise it could persist the identity anywhere, the session, cookies, etc, the inner layers of your application shouldn't have to care about such implementation details, they obtain the identity via the component, or from the request object, and that's it, they don't need to know anything else, then you can easily change how authentication is handled without breaking the rest of your application.
I really do like the easy way of using and integrating the "Admin on REST" (AOR) with Loopback, but I can't find out to get the relations in Loopback working.
Question
How can I use the Loopback API in AOR, when I use the relations types like hasAndBelongsToMany and HasMany?
I need to do Read, Update and Delete on an existing book to an existing author. But also as a datagrid view, where I can see which book relates to which author.
Example
I have a book which contains multiple authors and also authors who have written multiple books, which will be build as a GET /book/{id}/authors.
I am not sure how Loopback API is specific to you question - especially the part with relations types, but from the official react-admin documentation you can see how relations can be represented within a Datagrid.
Moreover, keep in mind that react-admin only deals with API calls, converting REST requests to HTTP requests and HTTP responses to REST.
This is done through the dataProvider, where you can write you custom functions.
The basic concept for the communication of you admin panel to your Loopback back-end though, are the requests, so I don't think that relation types have anything to do with react-admin.
I'm trying different ways of implement multi tenant AppEngine web RESTful interface.
One of them is to use part of the URL as the tenant name.
The problem is that I'm using Jersey as JAX-RS implementation for RESTful interface and I would like a url such as /tenant1/res1 to first be parsed by something that will take the /tenant1 part, set the namespace to tenant1 and then pass the rest of the URL to Jerseys' servlet for regular handling.
The something maybe either ServletFilter or Servlet or something I can't think of.
How can I implement such thing?
What are the possible problems of such implementation?
Thank you,
Ido.
I do exactly that but using Restlet. The namespace uniquely identifies the customer that a user belongs to.
The first URL fragment contains the namespace. I verify the namespace in a RESTLET authenticator (basically a filter) and when the authenticated user does not belong to the given namespace/customer I refuse to proceed.
I use the primary key of the customer as the namespace. This has the added advantage that a valid namespace/customer can be easily (mem-)cached, and I refuse any calls containing invalid namespaces.
Very happy with this setup and no problems encountered.