Download Personalization Platform for Multimodal Ubiquitous - RUN UNL PDF

TitlePersonalization Platform for Multimodal Ubiquitous - RUN UNL
LanguageEnglish
File Size7.2 MB
Total Pages180
Table of Contents
                            Introduction
	Motivation
	Description and Context
	Solution
	Main Contributions
	Report Structure
Related Work
	Web Services and Cloud Computing
		Web Services
		Authentication and Authorization
		Cloud Computing
	Personalization of Applications
		Social Itinerary Recommendation from User-generated Digital Trails
		My Own Web
		Service Platform for Rapid Development and Deployment of Context-Aware, Mobile Applications
		CXMS - A Context Management Framework
		Facebook Open Graph
		Google Personalized Search
		Other Related Projects
	Interacting with Public Displays
		Situated Displays
		Related Projects
		Public Display Interaction Techniques
	Geographical Data Analysis
		Geographic Coordinate System
		Distance Between Coordinates
		Acquiring Location
		Identifying Places
P2MUCA - Personalization Platform
	CAPE - Personalization Framework
		Requirements
		Data Model
		Personalization Algorithm
	Design Decisions
		Programming Language and Platform
		Service Type, Authentication and Authorization
		Data Storage
	Architecture
	Deployment
	P2MUCA HTTP API
	User Interface
		Developer Options
		End User Options
FCT4U - Interactive Public Display Application
	Design Decisions
		Development Platforms
		Presence Sensing
		Communication
	System Architecture
	Available Features
		Widgets
		Mobile Application
		Automatic Place Identification
	Personalization Applied to FCT4U
		Resources
		Parameters
		Personalizations
	User Study
		Participants and Design
		Results and Discussion
Conclusions and Future Work
	Conclusions
	Future Work
Appendix A - Personalizations
                        
Document Text Contents
Page 1

cover-msc-round


Pedro Emanuel Albuquerque e Baptista dos Santos

Licenciado em Engenharia Informática

Personalization Platform for Multimodal
Ubiquitous Computing Applications

Dissertação para obtenção do Grau de Mestre em
Engenharia Informática

Orientador : Nuno Manuel Robalo Correia, Prof. Catedrático,
Universidade Nova de Lisboa

Júri:

Presidente: Prof. Dr. José Augusto Legatheaux Martins

Arguente: Profa. Dra. Ana Paula Pereira Afonso

Vogal: Prof. Dr. Nuno Manuel Robalo Correia

Dezembro, 2013

Page 90

3. P2MUCA - PERSONALIZATION PLATFORM 3.3. Architecture

CAPE
Database

P2MUCA
Database

CAPE

P2MUCA HTTP API

OAuth 2.0
Resource Service

CAPE

P2MUCA
Website UI

OAuth 2.0
Authorization

Service

Figure 3.7: P2MUCA architectural overview

As already said, the use of the OAuth protocol protects data from unauthorized ac-
cess. This comes from the fact that an application must first get an access token and a
refresh token to use the personalization API, and those can only be obtained if a user
authorizes it. The access token can then be used by a pre-determined amount of time to
make API requests on behalf of an user, while the refresh token can be used to get a new
access token if the original one expires. A user can always revoke an application access
and both the access and refresh token are rendered useless, thus giving a user express
control over who can access their data.

Two common scenarios regarding the use of OAuth 2.0 can be seen in Figures 3.8 and
3.9. The first is the authorization code grant flow, where an application asks for permissions
from the user using its client id and gets an authorization code that can be exchanged for
access and refresh tokens by providing its client id and client secret. As the access token
can expire after a given time, the refresh token can be used to get a new authorization
token without the user having to go through the authorization page once again.

The second flow is called implicit grant flow and should be used in cases where the
client secret can not be used because it is impossible to keep it private (e.g., a browser
based application or native applications), while also providing an alternative simpler
flow. This way, only a short lived access token is issued as part of the redirect URI with
no companion refresh token. Once the access token expires, a new one must be requested
which means that the user must once again be redirected to the authorization URI. How-
ever, if the application is already authorized and the user is still logged in, the user should
be automatically redirected back to the application and the new access token delivered
to it through the redirect URI.

68

Page 91

3. P2MUCA - PERSONALIZATION PLATFORM 3.3. Architecture

It is also possible to exchange the client credentials (client id and client secret) for an
access token that can be used to make requests on behalf of the client itself. This flow is
depicted in Figure 3.10.

Client

P2MUCA Resource Owner Endpoint
/p2muca/oauth/authorize

P2MUCA P2MUCA Service Endpoint
/p2muca-service/someApiCall

client_id,
redirect_uri,

response_type
(code)

code

access_token

results

access_token,
refresh_token

(JSON)

client_id,
client_secret,

code,
redirect_uri,
grant_type

(authorization_code)
P2MUCA Authorization Server Endpoint

/p2muca/oauth/token

Figure 3.8: P2MUCA using OAuth 2.0 Authorization Code grant flow

Client

P2MUCA Resource Owner Endpoint
/p2muca/oauth/authorize

P2MUCA P2MUCA Service Endpoint
/p2muca-service/someApiCall

client_id,
redirect_uri,

grant_type (token),
response_type

(token)

access_token
(URL Encoded)

access_token

results

Figure 3.9: P2MUCA using OAuth 2.0 Implicit Grant flow

Client

/p2muca/oauth/token

/p2muca-service/someApiCall

client_id,
client_secret,

grant_type
(client_credentials)

access_token

access_token

results

Figure 3.10: P2MUCA using OAuth 2.0 Client Credentials Grant flow

69

Page 179

A. APPENDIX A - PERSONALIZATIONS

communicativeAholic

• weatherAholic→ notWeatherAholic

• communicative→ communicative

• menusAholic→ notMenusAholic

• newsAholic→ notNewsAholic

• Aholic→ notAholic

communicativeAholicAlone

• weatherAholic→ notWeatherAholic

• communicative→ communicative

• menusAholic→ notMenusAholic

• newsAholic→ notNewsAholic

• Aholic→ notAholic

• company→ alone

communicativeAholicAccompanied

• weatherAholic→ notWeatherAholic

• communicative→ communicative

• menusAholic→ notMenusAholic

• newsAholic→ notNewsAholic

• Aholic→ notAholic

• company→ accompanied

157

Page 180

A. APPENDIX A - PERSONALIZATIONS

communicativeAholicAccompanied w/friends

• weatherAholic→ notWeatherAholic

• communicative→ communicative

• menusAholic→ notMenusAholic

• newsAholic→ notNewsAholic

• Aholic→ notAholic

• company→ accompanied w/friends

none

• weatherAholic→ notWeatherAholic

• communicative→ notCommunicative

• menusAholic→ notMenusAholic

• newsAholic→ notNewsAholic

• Aholic→ notAholic

Table A.2: viewOrderpersonalization options

158

Similer Documents