Spring Boot - Can A Web Application Use Its Own Rest Api - spring-boot

So I'm new to Spring Boot and am trying to get my head around how it works. But I can't find some of the answers I'm looking for online so was hoping somebody might be able to help me out.
My first question is, can a web application use its own rest api to
manipulate data eg. get, post, put etc. or is the api just limited
to use by other applications/websites etc. If this is the case how does a a web
application manipulate it's data does it just use a seperate
conventional controller?
My second question is, let's say I've a piece of code like this
#GetMapping("/responsebody")
#ResponseBody
public UserAccount testingResponseBody(Principal principal) {
if(principal != null) {
UserAccount currentUser = userRepo.findByUserName(principal.getName());
return currentUser;
}else {
return null;
}
}
A simple piece of code that returns a JSON for the currentUser. The
thing that has me a little confused is why would someone want the
current user JSON to be visible at the corresponding URL i.e
localhost:8080/responsebody. I mean lets say the controller is accessed by an AJAX request. The data is only needed internally in the
application. Why display it to the world at that URL. I feel like I'm missing something important. Is there a way to make certain controller methods only usable within the application to manipulate data without showing it at a URL.
Also if anyone knows of any really good resources where I can get
these concepts to sink in it would be greatly appreciated.
Thanks guys, hope I didn't make it too long.

I think that if you expose path then every apps can access to that path. If you want to use internal, you can restrict that path using security for example like "only apps that have authority 'INTERNAL_CLIENT' should only be access to that path"

Related

How to read a Google People api response object [updated]

I'm new to Google's API and I'm having trouble reading the content of a People contact.
To get the details of a particular contact, references show this code should work [Edit: I updated the personfields]:
profile = service.people().get(resourceName='people/c63810788897573286', personFields='names')
The resourceName is the ID of a particular contact (that ID will only work for someone with access to my account). The server grabs it correctly and returns this:
<googleapiclient.discovery.Resource object at 0x10fd183c8>
How do I read the content of this object? I can't figure out from the documentation
I want to print out the Name. I'm pretty new to APIs, so maybe there is a standard way to read an HTTP object or maybe it's something unique to Google's API. Thanks for any advice
I found an answer in another somewhat related StackOverflow. I needed to the add .execute() to the call
profile = service.people().get(resourceName='people/c63810788897573286', personFields='names').execute()

Admin on rest add new resource to store dynamically

My project is structured like this.
As you can see there are three resources(posts, users, comments) defined.
So you cannot perform CRUD operations on any other resource. I am not using any custom clients (using aor-loopback rest client)
I would like to dynamically add new resources to the store so that I can access those tables/models/resources for CRUD. I know its possible (but don't know how), because we can update the store on the fly. Any help is appreciated.
I found the solution my problem. Sharing it for anyone who encounters the same.
import { DECLARE_RESOURCES } from 'admin-on-rest';
and use this action to re-initialise all the resources with an additional one.
Cheers.

Session object not available in WebAPI

I've got a webAPI that uses Entity Framework. I'm trying to cache some data in the session variable following along in this article:
https://msdn.microsoft.com/en-us/library/system.web.httpcontext.session(v=vs.110).aspx
I can't seem to do it though. The Session object isn't available.
In my controller, I try this:
Session["mappings"] = mappings;
...but it doesn't recognize what Session is.
I also try this:
HttpContext.Current.Session["mappings"] = mappings;
...and this:
Page.Session["mappings"] = mappings;
...but it doesn't know what HttpContext or Page are.
I'm including System.Web in my project references. I'm also including this in my web.config:
...just like this article says:
https://msdn.microsoft.com/en-us/library/ms178581(v=vs.110).aspx
...but to no avail.
My work colleague suggests it's because our webAPI is RESTful which means it's stateless, so no session object. However, we know there are ways around this. What I need is simply some way of persisting data in some kind of cache that will survive across several requests.
I also need something that will be available inside EF entities (not just the webAPI controller) is that's possible.
Does anyone know how to solve this problem? Thanks.
As your colleagues correctly suggested, an API is stateless, each request is separate and needs to have all the data required to complete the request.
You can add a caching layer however, but that is not going to be done via the Session object. Session makes no sense in an API.
Have a look here for some ideas: Caching Data in Web API

ValidateAntiForgeryToken breaks read on .NET Core with IdentityServer4

I am doing a basic read and write functionality to a IdentityServer4 application using .NET Core 2.0 and have come across an issue. When trying to load clients the ValidateAntiForgeryToken attribute seem to break my update.
I know that EF core does not support lazy loading so we are using an Unit Of Work pattern. I would create separate repositories for Client, ClientScopes, Secrets, etc. and grab the data for each. I will pass in a Func<> to allow filtering when grabbing ClientScopes etc. So a method call would look like this
ClientScopeResitory.GetAll(a => a.Client.Id == id)
which would then access the dbset like this
public IEnumerable GetAll(Func<T, object> predicate == null)
{
return predicate != null ? dbset.Where(predicate) : dbset
}
My issue is when loading the client in my read operation this works just fine. However when using the same code in my update where the ValidateAntiForgeryToken is present it breaks. What happens is in the creation of the repository during the read, the Clients are loaded in with the dbset. However, in the update, the clients are not. When the ValidateAntiForgery attribute is removed. The clients are loaded again and the update works fine. Anyone have any ideas what is going on. I can supply full code upon request. Thanks in advance.
Also, I apologies for any bad grammar or spelling, I wrote this in a hurry

"Default principal object cannot be set twice" error implementing WEB API with CSLA backend

Can anyone save some of my hair? :)
I'm trying to create an asp.net WEB API interface for an older CSLA (1.x/2.x era) project. I am testing by hard coding the login on every request in various ways (once in the startup code, as an authorization request filter, inside the individual route request etc etc). All the ways I tried work exactly once perfectly and then I get the infamous:
'Default principal object cannot be set twice.'
exception in BusinessPrincipal.vb (yeah I know it's very old, but it's released software, I can't upgrade CSLA)
I know that there is an issue where you need to set HttpContext.Current.User = Thread.CurrentPrincipal; due to some internal workings of the web API and I do that already, that has not resolved the issue.
I'd like to know if anyone has implemented a web api front end and how they handled this issue or any pointers as to what could be the solution.
Worst case scenario if I could at least just login once and keep that same principal without losing it I could implement a second layer of security, that woudld be acceptable, barring anything else is there some way to just login once and not lose that principal?
That BusinessPrincipal class would be in your code base, not in CSLA itself. The Csla.Security namespace does include a BusinessPrincipalBase that is probably the base class for your BusinessPrincipal.
Classes in that namespace are here in GitHub
It is true that you can only call AppDomain.SetPrincipalPolicy one time, but you should be able to set the Thread.CurrentPrincipal and HttpContext.Current.User multiple times.

Resources