Scenario :- I used Parse facebook Login in my app.
In my application UserA sends cookie to UserB? i want to store how many cookies UserA sent to UserB. also when UserB logs in he should be notified that how many cookies he received.I want to store and fetch these values through parse.UserA can send cookies to as many friends as he wants and all those friends should get updated about received number of cookies.
Possible Solution :- so for each friend of UserA 2 Objects should be created dynamically
a)sent number of cookies
b)received number of cookies
And when those friends login they fetch their own received-request-object on parse.
Problem :- i cant update the UserB objects from UserA login. since [PFUser currentUser] would only allow me to update UserA Objects and not UserB Objects.
I am new to programming and i dont want to create my own web-service backEnd.
Can I do this with Parse or should I try something Else?
You will need to learn about relational data, mentioned in the Parse website: https://parse.com/docs/ios_guide#objects-pointers/iOS
Basically you will need to create a new class for Cookie, add a new object of Cookie, set the relationship of the object to the sender (a PFUser object), and set another relationship to the receiver (another PFUser object).
PFObject *cookie = [PFObject objectWithClassName:#"Cookie"];
PFUser *sender = [PFUser currentUser];
PFRelation *sendingRelation = [sender relationforKey:#"sends"];
[sendingRelation addObject:cookie];
PFUser *receiver = //friend PFUser object;
PFRelation *receivingRelation = [receiver relationforKey:#"receives"];
[receivingRelation addObject:cookie];
Then you can use the relational query to get the number of sent or received cookies: https://parse.com/docs/ios_guide#queries-relational/iOS
Related
I would like to get a list of all the active users using API. When I use :
GET /workspace/{workspaceId}/users
I get a list of all the users, I wanted to use their "status" field to filter them out. The problem is all the users have "ACTIVE" status, no matter what their real status is (active or inactive).
I suppose it some sort of bug, right? Or is there some other way to get a list of active users?
status of user refers to the state in the system, i.e. whether has verified email address or not. It does not refer to the status of the user in any given workspace.
That information can be read from the list of memberships that is returned in the response. Filter the memberships by the id of the workspace and read its status.
Typically, the url would look like this: GET /workspace/{workspaceId}/users?active=true. The web service would handle this query string parameter like below:
public List<User> Get(bool active)
{
var users = GetActiveUsers(); // Call to database which has a query to get only active users.
return users;
}
I'd like to add a property to a Firebase user object. The user documentation says that I can only store additional properties using the Firebase real time database.
I am unsure on how this can works in practice.
What does the following mean in practice?
You cannot add other properties to the Firebase User object directly;
instead, you can store the additional properties in your Firebase
Realtime Database.
I interpret it as following:
"you cannot modify properties of a FIRUser object but you can combine this with additional objects"
I found the set function documentation which I interpet in this way:
var userRef = ref.child("users");
userRef.set({
newfield: "value"
});
Is this a sensible approach?
You're almost there. In the legacy Firebase documentation, we had a section on storing such additional user data.
The key is to store the additional information under the user's uid:
let newUser = [
"provider": authData.provider,
"displayName": authData.providerData["displayName"] as? NSString as? String
]
// Create a child path with a key set to the uid underneath the "users" node
// This creates a URL path like the following:
// - https://<YOUR-FIREBASE-APP>.firebaseio.com/users/<uid>
ref.childByAppendingPath("users")
.childByAppendingPath(authData.uid).setValue(newUser)
I've added a note that we should add this information in the new documentation too. We just need to find a good spot for it.
According to the Custom Claims documentation,
The Firebase Admin SDK supports defining custom attributes on user accounts. [...] User roles can be defined for the following common cases:
Add an additional identifier on a user. For example, a Firebase user could map to a different UID in another system.
[...] Custom claims payload must not exceed 1000 bytes.
However, do this only for authentication-related user data, not for general profile information, per the Best Practices:
Custom claims are only used to provide access control. They are not designed to store additional data (such as profile and other custom data). While this may seem like a convenient mechanism to do so, it is strongly discouraged as these claims are stored in the ID token and could cause performance issues because all authenticated requests always contain a Firebase ID token corresponding to the signed in user.
Use custom claims to store data for controlling user access only. All other data should be stored separately via the real-time database or other server side storage.
I am going to develop a rest service using Web API. For that we have a requirement that we have a number of parents who can able to login to the application as a parent. There is an access token provided for each user who accessing the application after successful login.
There is a service available for each parent to get the list of teachers who are teaching their child. There may be more than one child for a parent. The list of childid available at the client when parent get logged in.
So we need to pass childid with accesstoken of the user to the api. Which is the best method to pass. Is it a GET or POST including childid as json body?
What is the best method for creating service like this. GET or POST? including accesstoken in HEADER or any other way. like inside json?
One way of implementing this might be to give each user (parent) Claims representing their parentage of each child. These would then be added to the user's principal in the manner described in this article. Some data store (for example, a database table) would record which users (parents) are parents of which children. Finally, in the API action method, compare the id of the child whose information is requested to the list of child claims on the user's principal, and if the id isn't present, return a 4xx status code (probably a 403 Forbidden).
Something like:
// Cast the Thread.CurrentPrincipal
IClaimsPrincipal icp = Thread.CurrentPrincipal as IClaimsPrincipal;
// Access IClaimsIdentity which contains claims
IClaimsIdentity claimsIdentity = (IClaimsIdentity)icp.Identity;
// Access claims
if(claimsIdentity.Claims
.Where(c => c.ClaimType == "name-of-your-custom-claim")
.Select(c => c.Resource.ToString())
.Contains(childId)) { return new HttpResponseMessage(HttpStatusCode.Forbidden);
Should work. Haven't tested the code or checked that it compiles; it's an example to give the gist. I may clean it up later.
Let's assume I implemented token based authorization with a custom filter attribute as described here.
Let's also assume, I have a controller that returns tasks:
public IEnumerable<Task> Get()
{
// return tasks for authorized user
}
Now, how would I go about returning only the tasks for the authorized user? Passing the user ID as a query parameter is not an option - it is forbidden to request the tasks of a different user.
you could enrich the HttpRouteData from your action filter and read it in the controller action. actionContext.ControllerContext.RouteData.Values.Add("UserId", someVaue );
You could also use the System.Runtime.Remoting.Messaging.CallContext class ( GetData and SetData )
In the code in the sample you linked to, they are encrypting the user's name in the token. In the filter they are getting this token from an http header, decrypting it back to the username, and querying it against an AuthorizedUserRepository.
AuthorizedUserRepository.GetUsers().First(x => x.Name == RSAClass.Decrypt(token));
You can certainly use a userid instead of the name, and work against a real repository instead of this sample one. You could either do all of this over again in the controller action or constructor, or you could pass it along the route data or some ThreadStatic property. If you want to get really fancy, you could implement claims based security and set a claim on the current thread's principal. Really it doesn't matter how you pass it along.
Ultimately you would just use this value in a where clause of a query or linq statement to filter down to the data you want the user to be allowed to access.
When a user log into my asp.net site I use the following code:
FormsAuthentication.RedirectFromLoginPage(userid, false);
As I often need to use the userid I can then later get the userid by:
string userid = System.Web.HttpContext.Current.User.Identity.Name;
Now I also want to show the logged in username on each page and my questions is therefore where do I place the username best if I need to use it on every page. User.Identity.Name is already taken by the userid so I can't use that one. Another solution would be to get the username from the database on each page, but that seems like a bad solution.
So: Is the best way to use Sessions to store the username?
There are essentially 6 different ways to store information, each with it's own benefits and drawbacks.
Class member variables. These are only good for the life of one page refresh.
HttpContext variables. Like class member variables, only good for one page refresh.
ViewState, these are passed from page to page to keep state, but increase the size of the downloaded data. Also, not good for sensitive information as it can be decoded.
Cookies. Sent on each page request. Also not good for sensitive information, even encrypted.
Session. Not passed to the end user, so good for sensitive information, but it increases the resource usage of the page, so minimizing usage for busy sites is important.
Authentication Cookie User Data - This is like like cookies, but can be decoded with the authentication data and used to create a custom IIdentity provider that implements your desired Identity information, such as Name or other profile information. The size is limited, however.
You can store just about anything in SessionState in asp.net. Just be careful and store the right things in the right places (you can also use ViewState to store variables.
Check this out for how to use SessionState to store and retrieve variables across postbacks.
public string currentUser
{
get { return Session["currentUser"] as string; }
private set { Session["currentUser"] = value; }
}
Using sessions isn't a bad idea but make sure to check for NULL when retrieving the values for when the sessions time out.
Or you could pass the variable through in the URL e.g
/Set
Response.Redirect("Webform2.aspx?Username=" + this.txtUsername.Text);
/Read
this.txtBox1.Text = Request.QueryString["Username"];