I understand I can attach an alias to a previously anonymously identified users, but how can I explore their behavior before they sign up? (they don't appear on Mixpanel's Explore until the identify API is called)
Thanks
The way to do it is to call mixpanel.identify() (with no args) when the app starts for the first time.
Then when the user registers you call alias and identify with your internal id.
The way to do it is using mixpanel funnels.
Related
We have an application that needs to append data to users' designated Gsheet.
They should enter the sheet ID on our app, authorize it and then click export. Our app would then append a new row of data.
We are not clear what is the best or the necessary Oath 2 scope that is appropriate for that.
https://www.googleapis.com/auth/drive.file
or
https://www.googleapis.com/auth/spreadsheets
Any help is appreciated.
What you should do is check the documentation for what ever method you are trying to use. I am going to guess that you are using Method: spreadsheets.values.update
This method requires one of the following scopes
Which one you pick is up to you. They will both work. Technically if your not going to be accessing any of the google drive api methods then there's probably no reason to use the drive scope.
You can check the scopes#Sheets documentation for information on exactly what each scope gives you access to.
As you can see the sheets scope gives you access to all sheets a user has, while the drive.file scope will only give you access to files that where created by your app. Not just sheets.
We have two types of accounts in our company. One user type (type1) are the one that we create manually via an internal UI. Now we want to give the possibility to clients to register themselves from a public UI (type2).
We would like to activate the registration process for users of "type2" and disable it for users of "type1". Is it possible to control it somehow?
Thanks!
Edit:
I've discovered this REST API function:
https://host/parse/verificationEmailRequest
But unfortunately, it does not work for my use case. Any other idea?
So it seems that there is no such option on parse-server but as #Davi Macedo posted it's possible to hook on the beforeSave trigger of the user and sent the verified flag to true. What I did, instead, is to check on the email adapter what kind of user request to send email and block when the user is of "type1". Maybe the solution from #Davi Macedo is more elegant but also the second one was working fine for me for now. Thanks a lot for helping out!
I am a relatively inexperienced programmer.
I have managed to build a web api which uses basic authentication as per the following:
https://weblog.west-wind.com/posts/2013/Apr/18/A-WebAPI-Basic-Authentication-Authorization-Filter which is working very nicely (forced over ssl obviously). Inside the OnAuthorizeUser i check the un/pw against an mssql database, via a call to an internal class called "DB" where all my database interaction occurs.
So all Controller methods are filtered by the Basic Authentication ("decorated" at the Controller level) however, access to certain Controller Methods also needs to be limited depending on the user - so there is a need to understand the user permissions. Based on my limited former ASP.NET experience I think I would have stored the relevant user details in a Session (or possibly cache) however I have so far steered clear of this based on wanting to stick to the concept of having a RESTful application etc
Rightly or wrongly, in playing around I realised I could use a private static (instance?) of my User class inside my internal DB class and populate it at the time of initial authorisation. I also added a public method (public User getThisUser()) to return the private User. From within my Controller methods I create an instance of DB and am able to check the values etc.
I was very worried that I would have issues with the "scope" of this "static" User, so to test, I created a Controller method to simply return the User information from DB.getThisUser(). In doing so I have found that I can log in as multiple different users (using different browsers concurrently for example) and each one consistently returns the correct user information (as logged in).
I'm still not entirely convinced this is "safe" however reading through the details of implementing something like ASP.NET Identity as a possible alternative makes my head spin and really seems like massive overkill in this case - I'm not using Entity Framework and after much searching I could not find a single example of NOT using an ORM (I need a solution to work with an existing DB).
Is this destined to fail? Do I go back to considering session or cache? Something else? I would really appreciate any feedback / advice on this from all of you who are more experienced than me. Thanks in advance for any help.
i think you're getting a bit confused.
an API is supposed to be stateless, meaning no session. Yes, you have a controller which translates into an endpoint.
You can hit an endpoint with all the information required to satisfy the request and this is it. Don't think of an API as an actual application where all requests are linked somehow. Instead, think of it at an application where each request is separate and can come from anywhere and any user.
How does the application know which user sent a request? Well, it doesn't unless you pass that information in.
You don't fire a request saying GetMeUserDetails. The api has no idea what you want. Instead you would say GetMeUserDetails for userId 12345. Now, since your request contains all the information required to satisfy the request, the API can now give you what you expect.
If some calls require authentication, you might use some sort of tokens to identify the user, but again, the information is passed in via the token.
You probably realize what static means and how it works. you are not going to see problems until you try to send two or more requests at the same time and then you'll realize that the first call now contains the details of the second request because well, static ...
I am trying to create a Laravel policy (I think this might be best way to do it) that overwrites another policy under certain circumstances. I have two models that have a many to many relationship, accounts and programs.
I have a policy that prohibits viewing of accounts for users that do not have the account associated with a program that belongs to them. This works fine, but this also presents a problem. This makes it so a user cannot attach an account to a program, because they cannot see it.
What would be the best way to go about solving this? I was thinking about creating a custom policy, as Laravel docs say you can name a policy whatever you want and have it control any action, but I don't quite understand how that would work. I wrote an attach method on the program and account policy, but that doesn't seem to be working.
In summary, I want to restrict the user from seeing the account view page (if it is not associated with a program that belongs to them), but I want to allow them to attach the account to their program.
I an developing a chrome extension which doesn't has any sign up or sign in flow, instead depends on authentication of a separate web app. I started integrating mixpanel and tracking user events anonymously, Now i want to identify those anonymous users using "alias" and "identify" api. I have a user_id for identifying users from the web app exposed REST api. Now if i apply a boolean check and make sure i call mixpanel "alias(user_id)" once and call "identify(user_id)" every time user visits a page, I can see a user entry in explore tab of mixpanel but live events tab has a anonymous user with same user_id and its tracked data, I wish to link such anonymous users with appropriate user profiles.
Please help me with this if you have some understanding of mixpanel. I am new at this.
Since I didn't had a sign in or sign up flow, I cannot use
mixpanel.alias
Hence i am now calling
mixpanel.identify
As soon as user installs the plugin, Since "identify" api can be called any number of times for an user, We are able to track all future events as soon as plugin gets installed.
This way by not letting the user generate anonymous events we can handle such situation.