I am implementing a web app where users enter their personal information to store them onto a database, in this case MongoDB. This acts much like an address book. These services are implemented using a REST API (I am using Spring framework), where clients can call GET requests to view other people's personal information, POST to add their own information, and PUT to update. The Administrator of the DB can use DELETE To remove users.
I have implemented all the CRUD operations for the services on the server side. But I have one question:
When a client calls GET for a particular user to see his information, the request is returned as a JSON string, where the password field is visible. I do not want the client to see the password, obviously.
Now, I tried adding #JsonIgnoreProperties({"password"}) at the top of my model class on the server side. Although this works and the client cannot see the password, The password is also not even stored on the MongoDB database with this implementation. Because when I call db.users.find().pretty(), to list all the documents in the collection, I do not see the "password" field for any of the users.
I need some way for the password to be stored on the DB, but unable to be viewed by the client.
Here is one of the GET methods which finds a user by his username:
/* Get user by username */
#RequestMapping(method=RequestMethod.GET, value="/getByUsername")
public #ResponseBody User getUserByUsername(#RequestParam("username") String username) {
return repo.findByUsername(username);
}
The Model class is just a class with a bunch of String variables, and getters and setters.
Thanks
You can use the retrievedFields method available in Morphia.
getDs().createQuery(className)
.field("username").equal(username)
.retrievedFields(false, "password")
.get();
Related
I have created a register page in reactjs, where I am taking firstName, lastName, password, email from a user.
In the backend, I have created the application using SpringBoot to handle the request from frontend.
Now, I am able to store (temporarily) the register form data in http://localhost:8080/forms .
When the user enters the data in register form at the front end, the data is stored temporarily in the spring boot application in the url mentioned in the axios.
So, when I enter this url (in the browser), am able to see the list of registered users with their credentials in JSON format like this :
[{"firstName":"Bhavya", "lastName":"Gupta", "email":"abcd#a", "password":"zaqxsw","id":100}]
But this data is temporarily stored, so when I restart the server the data is no longer there.
submitBook= event =>{
event.preventDefault();
const book = {
firstName: this.state.firstName,
lastName: this.state.lastName,
password: this.state.password,
email: this.state.email
};
axios.post("http://localhost:8080/forms",book).then(response => {
if(response.data!=null){
this.setState({"show":true});
setTimeout(() => this.setState({"show":false}),3000);
} else {
this.setState({"show":false});
}
});
this.setState(this.initialState);
}
The complete code is available here
I want to store the register form data from front-end (client-side) into a MySQL database, so that I can perform login authentication on the data stored.
I have created MySQL database with 4 columns - firstName, lastName, email, password. I searched on the internet and read several answers in SO Sending data to database in React, referred several blogs and articles, but I am not able to understand how to achieve this.
Can anyone please help me out in solving this issue?
In a typical/modern web application, you have well defined roles/purposes for each part of the system. From your question, it appears that you intend for the roles to be interchanged and that might the source of your troubles here.
Let;s look closely at your set-up:
Client-side/Front-end (JavaScript/React)
This is simply an enabler for a user to interact with your actual application. In your set-up, this should render the form and capture registration data.
Server-side/Back-end (Java/SpringBoot)
This is your application layer where most processing happens (business logic).
In your set-up, this is where your MVC happens. And essentially, after any required validation, this layer then communicates with the Database.
Database-layer (SQL or NoSQL)
This is the layer that you utilize to store and persist data within your app. In your set-up, you are using MySQL to handle your data.
Already your backend is already exposing endpoints which you are consuming at the front-end via axios. Therefore the direct answer to your question lies in getting SpringBoot to work with your MySQL in order to persist your data.
Here is an official tutorial on how to access data with MySQL from the spring team.
For Posting Form data from ReactJS to MySQL database via Spring Boot Application, I have written blogs, that gives a detailed explanation and a step by step method to connect front end part with backend .
Refer to these blogs :
Prerequisites to POST form data from ReactJS to an API endpoint : Part 1
Initial Setup for creating a basic React App: Part 2
Posting Form data from ReactJS to MySQL database via Spring Boot Application: Part 3
I am wondering if implicitly using the currently authenticated user as context for API interactions is RESTful or not. For example, assuming all my API calls are authenticated using standard HTTP security:
Should a query to retrieve a list of orders for the user be explicit?
NO: http://example.com/orders
YES: http://example.com/orders?userid=1234
When placing a POST to create a new order, should the JSON contain the user?
NO: { orderref: 'EXAM/1', items: { ... } }
YES: { userid: 1234, orderref: 'EXAM/1', items: { ... } }
Either way I'll be securing so that the API will only allow actions for the current user, but should I make the API caller state the userid for each action?
I would say you should only pass the user ID as a query if you have access to many user's orders and need to filter them by user.
If a user has access to only their own orders they should not have to pass a user ID - the base queryset should limit it based on their own authentication details. Arguably that may not be RESTful, but don't worry about that - most API's may not be 100% RESTful and you should do what makes sense for your application rather than worrying about whether it's RESTful - it's a guide, not a cast-iron requirement.
In any case depending on what type of authentication you use (BASIC or TOKEN), you have to send the user info in your API call (Headers) which makes the request to the API.
So when you say if it is valid to use the authenticated user from the Context, of course it is
sample code here
The api call
headers.Authorization = 'Bearer ' + localStorage.getItem("tokenkey");
Obtain user from the request
RequestContext.Principal.Identity.Name
Is it RESTful? I would argue that: yes it is. There is no REST spec, so there's nothing really that says that it isn't. HTTP does allow this, and HTTP Caches should actually by default consider responses to GET requests with an Authorization header as private.
Should you use this design? I don't know! I think there's benefits to having per-user endpoints, because in the future it might allow User A to inspect the orders of User B.
In our API we actually have an example of an API similar to yours, but we do both.
We have a /users/1234 endpoint.
We also have a /current-user endpoint.
Initially the /current-user endpoint just redirected to the uri of the actual current user, but eventually we decided we're actually just going to return the full object without redirecting (due to browsers not behaving nicely with redirects).
The current-user endpoint does have a self link still that points to the real user resource.
So to sum it up. I think you are in the clear here, but I argue that there are strong design benefits to creating resources that have a consistent representation regardless of who's looking at it. It makes things a bit simpler and nicer.
And also don't forget that there's no reason why you can't, if you are actually following REST. All a client should care about is that there's a link somewhere to a list of orders and it shouldn't care what it's url is.
+1 for Matthew Daly's answer. Especially when the authenticated user has only access to his own orders (I assume that).
In case that your authenticated user can access more order lists than only his own, I would go like that:
/orders: the authenticated user's orders.
/orders/123: the specific user's orders.
If 123 equals the authenticated user's id - so what? It would be most likely no problem case for your client.
By designing a REST service you think of the comfort that the developers could have, when they use your API. I would say, this one is a comfortable solution.
Should a query to retrieve a list of orders for the user be explicit?
NO: http://example.com/orders
YES: http://example.com/orders?userid=1234
When placing a POST to create a new order, should the JSON contain the
user?
NO: { orderref: 'EXAM/1', items: { ... } }
YES: { userid: 1234, orderref: 'EXAM/1', items: { ... } }
If user queries only its own orders, user id shouldn't be passed explicitly in the query - you should pass user token in HTTP header and your code should extract user id by provided token and determine whether authorized user has rights to see or modify particular data.
In case you want to let one user get or modify another user data then you would make additional endpoint - something like users/{userId}/orders or users/{userId}/orders/{orderId}. You would still pass user token via HTTP header and your implementation should check if user has admin rights for this action.
I'm using WSO2 Products, IS and API Gateway.
My use case is : I have a ReadOnly LDAP User Store that have some attributes such name, surname, email etc.. Obviously in LDAP Read Only i can't add new user's property, for example I would like to add a attribute (claime) with name "Profile". I found some documentation but i don't understand how to do this. (https://docs.wso2.com/display/IS510/Writing+a+Custom+User+Store+Manage).
If I understand well, I have to create a new User Store (such MYSQL DB) where i can mapping the LDAP's users and i can also add custom attribute.
This is the right way to do it?
And another question is : If the consideration above is right, How can I do provisioning of the 2 User Store ?
One way to do it without any code is as follows.
Create a new claim in WSO2 according to your preference, e.g. "Profile".
Map this claim to an existing unused attribute of your ReadOnly LDAP.
e.g. Map profile to FAX or Street Addres etc.
Modify configuration of your service provider and send this new claim in authentication response to your service provider.
Now you can update this LDAP attribute with whatever value you want and Service Provider will receive this as claim named as "profile".
I'm building a REST back end based on spring and i'm using spring security to secure the requests. But i'm lookin for an issue to login by sending parameters in json rather than defaults parameters sent by the default login page of spring security.
I'm working with spring security 4.0.1 and spring 4.1
Any issue please?
If you're using just username and password, you can simply add a new filter to the stack, akin to the existing UsernamePasswordAuthenticationFilter, that would react to a specific URL only (just like the default one reacts to j_spring_security_check only), parse the JSON and create the very same UsernamePasswordAuthenticationToken that the default filter creates. This leaves the auth provider the same as the token didn't change.
If you need more fields in addition to username and password, either create a new token type (or use existing one if it makes sense) and a new auth provider that can deal with that token type. You can also just cram extra fields into UsernamePasswordAuthenticationToken using setDetails(), but this is a bit hacky.
I am trying to validate that a username is unique on a registration form and would like to verify the uniqueness of the username right after the client types it as opposed to performing this server side after the form has been submitted.
Should I collect a resultSet from the database, store it in an array and then pass this along to the jsp page in the form of a bean (I am using a model 2 design so the user passes through a servlet before arriving at the jsp page)? What if the array is very large? How do I bring this data into javascript?
Alternatively, is there a way to do the query using ajax and javascript all on the client side? Maybe its possible to somehow run the query in the background?
I am really just looking for some direction because I am clueless as to what to even begin researching something like this. Is this even a smart move, performance wise?
I'd use "AJAX" for this.
Here's one approach: set up a blur() handler on the username text field of your form. When the blur() method is invoked, you post the username to the backend code; it verifies it and returns some appropriate response. You then parse the response and change the CSS class on the username text field (e.g., turning it red) -- or do whatever else visually you want to do to indicate "username in use."
Either way, you've got to get the username from the client to the server for verification; you wouldn't want any mechanism which allowed the client to directly use the DB (think security/exploits/etc).
If you're not already familiar, check out jQuery (http://jquery.com/) to make your client-side life much easier.