I am new to Pinpoint and trying to understand how endpoint/endpointId works in Pinpoint semantics. From the aws doc:
When a user starts a session (for example, by launching your mobile app), your mobile or web application can automatically register (or update) an endpoint with Amazon Pinpoint.
Does that mean each time of the app launching, there is a new endpoint/endpointId? Will it register a new endpoint if the current session ends or the user kill and relaunch the app?
Is there a way I can get the endpoint/endpointId in the app programmatically?
Yes, the endpoint is the same for each unique device, email, etc. It needs to be the same so that Amazon knows where to send push notifications, for example, if you run a targeted campaign. If the user kills and relaunches the app, then the same endpoint is used. This goes for both authenticated and unauthenticated users. Thus, I would have reason to believe that if the current session ends (i.e. the user has to re-authenticate), then they have the same endpoint. This makes sense because every device (the device itself) needs a unique identifier. In order to better answer your question, I have personally tested the below and confirmed:
If one user logs out, and another logs in [on the same device], the endpoint ID remains the same. The purpose of the code below registers a user ID with a specific endpoint. You can also modify the code below to print the endpoint ID, as you requested.
At the top of your AppDelegate, put this, assuming you're using Swift and AWS Cognito for user authentication:
var pinpoint: AWSPinpoint?
... in didFinishLaunching, put this:
self.pinpoint = AWSPinpoint(configuration:AWSPinpointConfiguration.defaultPinpointConfiguration(launchOptions: launchOptions))
if let targetingClient = pinpoint?.targetingClient {
if let username = AppDelegate.defaultUserPool().currentUser()?.username {
let endpoint = targetingClient.currentEndpointProfile()
// Create a user and set its userId property
let user = AWSPinpointEndpointProfileUser()
user.userId = username
// Assign the user to the endpoint
endpoint.user = user
// Update the endpoint with the targeting client
targetingClient.update(endpoint)
print("Assigned user ID \(user.userId ?? "nil") to endpoint \(endpoint.endpointId).\n")
}
}
Related
How are you guys , my problem that my flutter app is connected to mysql db , when the user is registered a string with the class name is saved to shared preferences and there is a wall to post some posts on it , is there any way to work with fcm bassed on the shared preferences string ? Like if the user has this string and posted let all users with the same string get notifications i hope i could make it more uderstandable but i dont know how ! Thanks
This sounds like a perfect use-case for using topics to target those messages. Step-wise:
Each device subscribes to the topic based on their class. If they can have multiple classes, they'd subscribe to all topics for those classes.
You then send the message to the correct topic for its class, and FCM will deliver it to all devices subscribed to that topic.
As usual, you will need to perform the actual send operation from a trusted environment, such as your development machine, a server you control, or Cloud Functions.
you will get the token id from the device which you can store to the user table so it will use while giving the notification to every device.
For getting the token :
_firebaseMessaging.getToken().then((String token) {
assert(token != null);
setState(() {
_homeScreenText = "Push Messaging token: $token";
});
print(_homeScreenText);
});
this token variable which you can store to the user table and use it while giving the notification to every device.
I am having a rather weird problem with Chris Kacerguis’ CodeIgniter REST Server.
Problems:
1) I am NOT loading the CodeIgniter session library, even then new entries are being created in the ci_sessions database table, everytime I am making an HTTP Request to my REST Api.
2) A brand new entry is being created (and the old entry is NOT being updated) in the db, on every HTTP Request, even when the IP Address is remaining the same.
This is my config.php file:
$config['sess_driver'] = 'database';
$config['sess_cookie_name'] = 'ci_session';
$config['sess_expiration'] = 0;
$config['sess_save_path'] = 'ci_sessions';
$config['sess_match_ip'] = TRUE;
$config['sess_time_to_update'] = 300;
$config['sess_regenerate_destroy'] = TRUE;
$config['cookie_prefix'] = '';
$config['cookie_domain'] = '';
$config['cookie_path'] = '/';
$config['cookie_secure'] = FALSE;
$config['cookie_httponly'] = FALSE;
I tried, individually and in combination, the following things:
$config['sess_match_ip'] = FALSE;
$config['sess_time_to_update'] = 0;
$config['sess_regenerate_destroy'] = FALSE;
and
$config['cookie_domain'] = '.mydomain.com';
But nothing worked.
Is this normal or some kind of a bug? What am I doing wrong? Anyone else having the same problem?
Another thing is that, I am not facing this issue in vanilla CodeIgniter. There, everything is working fine and as expected.
Update
I found something while struggling with the second part of the problem.
Two session entries are being created in the database while making the first HTTP Request - one for the client and another one for the REST Server. From the second request, the client 'version' of the cookie is being UPDATED while the server 'version' is being RE-GENERATED.
For the 1st part of the problem:
As pointed out by #JamesLalor in the comments,
You must either be autoloading the session
OR
You are using some external library which is, in turn, loading the session library.
For the 2nd part of the problem:
The below solution may not be the best, but it worked for me.
Multiple sessions creation problem occurs when:
You have both REST Server and Client within the same CodeIgniter Application directory
AND
Session library is auto-loaded
To the Client, the user is the consumer. A session is created for the user, having the IP address of that user. A cookie is set on the user’s browser with which the session is validated and updated (or newly created) based on the validation.
To the REST Server, the Client is the consumer. Here also a session is created (if both condition 1 and 2 above is fulfilled), but this time, it is for the Client, and this session has the IP address of the server on which the Client resides (if condition 1 above is fulfilled, then it is the IP address of the same server on which your app resides). But this time a cookie could not be set, as the consumer is not a browser. Hence, the session validation fails and a new session is created each time the page loads.
Solution:
REST is stateless and every request should contain all the information required to fulfil the request. Therefore, using sessions (whose sole job is to maintain user’s state) on REST Server is considered a bad practice. It is the job of the Client to maintain the user’s session and pass the required information to the REST Server on each and every request.
Therefore, assuming that you would not be needing session within REST Server, the solution is to remove session from autoload[‘libraries’] list, within autoload.php file, and load the library within the Client constructor (or when you need it).
Sorry for grammatical errors and/or bad English. It is not my native language.
I am using Box Api v2 (java) for integrating my webapp with Box.com.
I forward the user to the authorize url
https://www.box.com/api/oauth2/authorize?response_type=code&client_id=client-id
..and receive the 'code' at my redirect end-point. Using this code, I am able to get the access_token and refresh_token. I know that access_token is valid only for 1 hr.
But can I re-use the access_token within this 3600 sec period?
eg:a user comes back within 30 minutes and tries to fetch/put files
In this scenario, I will need to create a new BoxClient.
So what is the recommended method of client authentication using the existing access token?
If answerer can paste code snippets using the box java api, it would be quite helpful.
Or is the refreshing to get new access_token and refresh_token, the only method available?
BoxClient client = new BoxClient(MY_CLIENT_ID, MY_CLIENT_SECRET);BoxOAuthManager mgr = client.getOAuthManager();
// This is refresh
BoxOAuthRequestObject requestObject = BoxOAuthRequestObject.refreshOAuthRequestObject(REFRESH_TOKEN, MY_CLIENT_ID, MY_CLIENT_SECRET);
BoxOAuthToken newToken = mgr.refreshOAuth(requestObject);
client.authenticate(newToken);
Yes, you can re-use the access token within the 3600-second period. A common pattern for web applications is to store the access_token and refresh_token (and optionally their expiration datetimes) in a database record associated with the user.
what is the recommended method of client authentication using the existing access token?
You'll use the same authentication method as when you first acquired the access token. You don't have to do anything special to reuse it. If the access_token is expired, as determined by either an expiration timestamp comparison or 401 response, you can use the refresh_token to get a new token pair. By refreshing and persisting the token pair in this manner you can keep the user authenticated indefinitely.
BoxOAuthToken accessToken = new BoxOAuthToken(Map) will work here.
// where Map contains
{
"exprires_in":"3600",
"token_type":"bearer",
"refresh_token":"<refresh_token>",
"access_token":"<access_token>"
}
Map authMap;
BoxOAuthToken accessToken = new BoxOAuthToken(authMap);
client.authenticate(newToken);
after reading the oauth documentation on box's website, I understand the steps to get access_token and refresh_token, which requires authorization_code.
step1: send Get request to https://www.box.com/api/oauth2/authorize?response_type=code&client_id=CLIENT_ID&state=authenticated&redirect_uri=https://www.appfoo.com
step2: after entering credentials of box in browser and then click the "Allow" button, redirect to the specified redirect_uri with state=authenticated&code=AUTHORIZATION_CODE
step3: now with the AUTHORIZATION_CODE in the redirect url from step2, getting access_token can be done programmatically, by sending POST request to https://www.box.com/api/oauth2/token with AUTHORIZATION_CODE, client_id, client_secret in body and then parsing the returned json response.
My question is: is it possible to programmatically do step1 and step2 instead of via browser?
thank you very much!
The current OAuth 2 flow requires the user to go through the browser and can't be done programmatically.
It is possible, just imitate every form with cURL and on second step post cookies.
First time you will need 3 requests, next time only one (if refresh_token isn't expired, otherwise 3 again)
The point about imitating the browser transactions is a good one but instead of using cURL you would want to use a higher level tool like mechanize (available for ruby, perl and python). It will handle the cookies for you and can programatically traverse forms and links. Good for page scraping and writing scripts to order hot concert tickets from TicketMaster too!
If you have the authorization code, you then should be able to get the OAuth Token(access_token, refresh_token) via SDK, correct?
In response to aIKid, this is what I first do to get a BoxClient
BoxClient client = new BoxClient(clientId, clientSecret);
Map<String,Object> authToken = new HashMap<String,Object>();
authToken.put("exprires_in","3600");
authToken.put( "token_type","bearer");
authToken.put("refresh_token", clientRefreshToken);
authToken.put("access_token",clientAccessToken);
BoxOAuthToken oauthToken = new BoxOAuthToken(authToken);
client.authenticate(oauthToken);
return client;
Then, I have this to create a new user,
BoxUser createdUser = new BoxUser();
BoxUserRequestObject createUserRequest = BoxUserRequestObject.createEnterpriseUserRequestObject("someEmail.domain.com", "test user");
createdUser = client.getUsersManager().createEnterpriseUser(createUserRequest);
Now I'm trying to figure out how to do the RUD part of my CRUD operations on users and groups.
I need to log unique user sessions in Webmatrix / Razor / ASP.NET Web Pages. Does _appstart fire just when the app spins up the first time in IIS or does it fire once per unique user hit? If just once, how do I capture unique user sessions & settings?
UPDATE: I wasn't sure if the Global.asax events were fired under Razor / ASP.NET WebPages. I tested it out and the Session_Start event fires just fine. Question resolved.
void Session_Start(object sender, EventArgs e)
{
// Code that runs when a new session is started
Dictionary<DateTime, String> d = new Dictionary<DateTime, String>();
Application.Lock();
if (Application["d"] != null)
{
d = (Dictionary<DateTime, String>)Application["d"];
}
d.Add(DateTime.Now, HttpContext.Current.Session.SessionID);
Application["d"] = d;
Application.UnLock();
}
To directly answer your question, _AppStart runs when the first user hits your site. Future users to the site do NOT cause _AppStart to run. There is no specific page or place to put code that runs for each unique user.
What you want to do is take a look at the ASP.Net Session object. In your page, you can store and retrieve data from Session like so:
#{
// Retrieve
var someSetting = Session["SomeSetting"]
// Store
Session["SomeSetting"] = someSetting;
}
ASP.Net will take care of making sure that the setting is stored per-browser-instance using Session Cookies. Note that if you're in a Web Farm environment, you'll need something more robust, but when you're talking about a single server, this should be fine.
If you want some more info, here's the official documentation for ASP.Net Session State: http://msdn.microsoft.com/en-us/library/ms178581.aspx
You have asked about logging "unique user sessions", which is a little confusing. All sessions are unique, but not all sessions belong to unique visitors. Returning visitors will start new sessions. If you want to keep a count of sessions, you can hook into the Session_Start event in Global.asax. If you want to count unique visitors, use cookies. Set them when a user visits if one hasn't already got a cookie. Ensure that their expiry is some time well into the future. If the visitor hasn't got a tracking cookie for your site, they must be new (or they might have deleted their cookie...)