Re: [Architecture] [APIM 3.1.0] Support externalizing login/logout URLs (/authorize and /oidc/logout)
On Tue, Jan 7, 2020 at 12:27 PM Malintha Amarasinghe
wrote:
>
>
> On Tue, Jan 7, 2020 at 12:23 PM Harsha Kumara wrote:
>
>>
>>
>> On Tue, Jan 7, 2020 at 12:20 PM Malintha Amarasinghe
>> wrote:
>>
>>> Hi,
>>>
>>> Currently, we do not support $subject and we always use the local IDP as
>>> the login/logout URLs (/authorize and /oidc/logout). In normal cases, this
>>> works without issues. But when it comes to configuring federated login with
>>> facebook, google etc, it is required to use IS (IS as KM) as the
>>> intermediate IDP which has the required authenticators to support
>>> facebook/google logins. In those cases, we need to point the local IDP to
>>> the IS/KM and the IS/KM points to Facebook as a federated login. But this
>>> flow has unnecessary one additional hop caused by the local IDP.
>>>
>>> As a solution, we plan to support externalizing the IDP URL (used for
>>> /authorize and /oidc/logout).
>>>
>>> [image: image.png]
>>>
>>> The plan is to introduce new configs as below:
>>>
>>> *api-manager.xml*
>>>
>>> {% if apim.idp is defined %}
>>>
>>>
>>>
>>> {{apim.idp.authorize_endpoint}}
>>>
>>> {{apim.idp.oidc_logout_endpoint}}
>>>
>>>
>>> {% endif %}
>>>
>>> *deployment.toml*
>>>
>>> #[api.idp]
>>> #authorize_endpoint = "https://localhost:9444/oauth2/authorize;
>>> #oidc_logout_endpoint = "https://localhost:9444/oidc/logout;
>>>
>> Token endpoint will be pointed to gateway?
>>
>
> No, it will still use the local endpoints eg;
> https://localhost:9443/oauth2/token. All the backend calls (generate
> token, DCR, refresh token) will use the local hardcoded endpoints in 9443
> port.
> Hope that would not cause an issue?
>
Yes that should be fine. Since we do share databases in this scenario, it
should be fine to go with the local endpoints.
>
> Thanks!
>
>>
>>> By default, the server will use the local IDP for login/logout. Only, if
>>> the above URLs are configured, they will be used instead of the default
>>> ones.
>>>
>>> Thoughts are highly appreciated.
>>>
>>> Thanks!
>>> Malintha
>>>
>>> --
>>> Malintha Amarasinghe
>>> *WSO2, Inc. - lean | enterprise | middleware*
>>> http://wso2.com/
>>>
>>> Mobile : +94 712383306
>>>
>>
>>
>> --
>>
>> *Harsha Kumara*
>>
>> Technical Lead, WSO2 Inc.
>> Mobile: +94775505618
>> Email: hars...@wso2.coim
>> Blog: harshcreationz.blogspot.com
>>
>> GET INTEGRATION AGILE
>> Integration Agility for Digitally Driven Business
>>
>
>
> --
> Malintha Amarasinghe
> *WSO2, Inc. - lean | enterprise | middleware*
> http://wso2.com/
>
> Mobile : +94 712383306
>
--
*Harsha Kumara*
Technical Lead, WSO2 Inc.
Mobile: +94775505618
Email: hars...@wso2.coim
Blog: harshcreationz.blogspot.com
GET INTEGRATION AGILE
Integration Agility for Digitally Driven Business
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM 3.1.0] Support externalizing login/logout URLs (/authorize and /oidc/logout)
On Tue, Jan 7, 2020 at 12:23 PM Harsha Kumara wrote:
>
>
> On Tue, Jan 7, 2020 at 12:20 PM Malintha Amarasinghe
> wrote:
>
>> Hi,
>>
>> Currently, we do not support $subject and we always use the local IDP as
>> the login/logout URLs (/authorize and /oidc/logout). In normal cases, this
>> works without issues. But when it comes to configuring federated login with
>> facebook, google etc, it is required to use IS (IS as KM) as the
>> intermediate IDP which has the required authenticators to support
>> facebook/google logins. In those cases, we need to point the local IDP to
>> the IS/KM and the IS/KM points to Facebook as a federated login. But this
>> flow has unnecessary one additional hop caused by the local IDP.
>>
>> As a solution, we plan to support externalizing the IDP URL (used for
>> /authorize and /oidc/logout).
>>
>> [image: image.png]
>>
>> The plan is to introduce new configs as below:
>>
>> *api-manager.xml*
>>
>> {% if apim.idp is defined %}
>>
>>
>>
>> {{apim.idp.authorize_endpoint}}
>> {{apim.idp.oidc_logout_endpoint}}
>>
>>
>> {% endif %}
>>
>> *deployment.toml*
>>
>> #[api.idp]
>> #authorize_endpoint = "https://localhost:9444/oauth2/authorize;
>> #oidc_logout_endpoint = "https://localhost:9444/oidc/logout;
>>
> Token endpoint will be pointed to gateway?
>
I don't think so. The key manager of the gateway can be something else
which does not know how to validate the token.
>
>> By default, the server will use the local IDP for login/logout. Only, if
>> the above URLs are configured, they will be used instead of the default
>> ones.
>>
>> Thoughts are highly appreciated.
>>
>> Thanks!
>> Malintha
>>
>> --
>> Malintha Amarasinghe
>> *WSO2, Inc. - lean | enterprise | middleware*
>> http://wso2.com/
>>
>> Mobile : +94 712383306
>>
>
>
> --
>
> *Harsha Kumara*
>
> Technical Lead, WSO2 Inc.
> Mobile: +94775505618
> Email: hars...@wso2.coim
> Blog: harshcreationz.blogspot.com
>
> GET INTEGRATION AGILE
> Integration Agility for Digitally Driven Business
>
--
*Nuwan Dias* | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM 3.1.0] Support externalizing login/logout URLs (/authorize and /oidc/logout)
On Tue, Jan 7, 2020 at 12:23 PM Harsha Kumara wrote:
>
>
> On Tue, Jan 7, 2020 at 12:20 PM Malintha Amarasinghe
> wrote:
>
>> Hi,
>>
>> Currently, we do not support $subject and we always use the local IDP as
>> the login/logout URLs (/authorize and /oidc/logout). In normal cases, this
>> works without issues. But when it comes to configuring federated login with
>> facebook, google etc, it is required to use IS (IS as KM) as the
>> intermediate IDP which has the required authenticators to support
>> facebook/google logins. In those cases, we need to point the local IDP to
>> the IS/KM and the IS/KM points to Facebook as a federated login. But this
>> flow has unnecessary one additional hop caused by the local IDP.
>>
>> As a solution, we plan to support externalizing the IDP URL (used for
>> /authorize and /oidc/logout).
>>
>> [image: image.png]
>>
>> The plan is to introduce new configs as below:
>>
>> *api-manager.xml*
>>
>> {% if apim.idp is defined %}
>>
>>
>>
>> {{apim.idp.authorize_endpoint}}
>> {{apim.idp.oidc_logout_endpoint}}
>>
>>
>> {% endif %}
>>
>> *deployment.toml*
>>
>> #[api.idp]
>> #authorize_endpoint = "https://localhost:9444/oauth2/authorize;
>> #oidc_logout_endpoint = "https://localhost:9444/oidc/logout;
>>
> Token endpoint will be pointed to gateway?
>
No, it will still use the local endpoints eg;
https://localhost:9443/oauth2/token. All the backend calls (generate token,
DCR, refresh token) will use the local hardcoded endpoints in 9443 port.
Hope that would not cause an issue?
Thanks!
>
>> By default, the server will use the local IDP for login/logout. Only, if
>> the above URLs are configured, they will be used instead of the default
>> ones.
>>
>> Thoughts are highly appreciated.
>>
>> Thanks!
>> Malintha
>>
>> --
>> Malintha Amarasinghe
>> *WSO2, Inc. - lean | enterprise | middleware*
>> http://wso2.com/
>>
>> Mobile : +94 712383306
>>
>
>
> --
>
> *Harsha Kumara*
>
> Technical Lead, WSO2 Inc.
> Mobile: +94775505618
> Email: hars...@wso2.coim
> Blog: harshcreationz.blogspot.com
>
> GET INTEGRATION AGILE
> Integration Agility for Digitally Driven Business
>
--
Malintha Amarasinghe
*WSO2, Inc. - lean | enterprise | middleware*
http://wso2.com/
Mobile : +94 712383306
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM 3.1.0] Support externalizing login/logout URLs (/authorize and /oidc/logout)
On Tue, Jan 7, 2020 at 12:20 PM Malintha Amarasinghe
wrote:
> Hi,
>
> Currently, we do not support $subject and we always use the local IDP as
> the login/logout URLs (/authorize and /oidc/logout). In normal cases, this
> works without issues. But when it comes to configuring federated login with
> facebook, google etc, it is required to use IS (IS as KM) as the
> intermediate IDP which has the required authenticators to support
> facebook/google logins. In those cases, we need to point the local IDP to
> the IS/KM and the IS/KM points to Facebook as a federated login. But this
> flow has unnecessary one additional hop caused by the local IDP.
>
> As a solution, we plan to support externalizing the IDP URL (used for
> /authorize and /oidc/logout).
>
> [image: image.png]
>
> The plan is to introduce new configs as below:
>
> *api-manager.xml*
>
> {% if apim.idp is defined %}
>
>
>
> {{apim.idp.authorize_endpoint}}
> {{apim.idp.oidc_logout_endpoint}}
>
>
> {% endif %}
>
> *deployment.toml*
>
> #[api.idp]
> #authorize_endpoint = "https://localhost:9444/oauth2/authorize;
> #oidc_logout_endpoint = "https://localhost:9444/oidc/logout;
>
Token endpoint will be pointed to gateway?
>
> By default, the server will use the local IDP for login/logout. Only, if
> the above URLs are configured, they will be used instead of the default
> ones.
>
> Thoughts are highly appreciated.
>
> Thanks!
> Malintha
>
> --
> Malintha Amarasinghe
> *WSO2, Inc. - lean | enterprise | middleware*
> http://wso2.com/
>
> Mobile : +94 712383306
>
--
*Harsha Kumara*
Technical Lead, WSO2 Inc.
Mobile: +94775505618
Email: hars...@wso2.coim
Blog: harshcreationz.blogspot.com
GET INTEGRATION AGILE
Integration Agility for Digitally Driven Business
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] [APIM 3.1.0] Support externalizing login/logout URLs (/authorize and /oidc/logout)
Hi,
Currently, we do not support $subject and we always use the local IDP as
the login/logout URLs (/authorize and /oidc/logout). In normal cases, this
works without issues. But when it comes to configuring federated login with
facebook, google etc, it is required to use IS (IS as KM) as the
intermediate IDP which has the required authenticators to support
facebook/google logins. In those cases, we need to point the local IDP to
the IS/KM and the IS/KM points to Facebook as a federated login. But this
flow has unnecessary one additional hop caused by the local IDP.
As a solution, we plan to support externalizing the IDP URL (used for
/authorize and /oidc/logout).
[image: image.png]
The plan is to introduce new configs as below:
*api-manager.xml*
{% if apim.idp is defined %}
{{apim.idp.authorize_endpoint}}
{{apim.idp.oidc_logout_endpoint}}
{% endif %}
*deployment.toml*
#[api.idp]
#authorize_endpoint = "https://localhost:9444/oauth2/authorize;
#oidc_logout_endpoint = "https://localhost:9444/oidc/logout;
By default, the server will use the local IDP for login/logout. Only, if
the above URLs are configured, they will be used instead of the default
ones.
Thoughts are highly appreciated.
Thanks!
Malintha
--
Malintha Amarasinghe
*WSO2, Inc. - lean | enterprise | middleware*
http://wso2.com/
Mobile : +94 712383306
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] PDF Report Generation for APIM Analytics
> > It would be better if the header and footer are customizable in the > generated report since customers might wish to add their logos, copyrights > to the generated report. > We can get required stuff ( ex: logo image of a given size, footer text > etc ) as inputs and if not given fallback to defaults. +1 for this idea. On Mon, Jan 6, 2020 at 10:54 PM Tanya Madurapperuma wrote: > It would be better if the header and footer are customizable in the > generated report since customers might wish to add their logos, copyrights > to the generated report. > We can get required stuff ( ex: logo image of a given size, footer text > etc ) as inputs and if not given fallback to defaults. > > On Mon, Jan 6, 2020 at 10:48 PM Harsha Kumara wrote: > >> >> >> On Mon, Jan 6, 2020 at 10:45 PM Kasun Thennakoon >> wrote: >> >>> Hi Fazlan, >>> >>> This analytics report looks much better than the reports generated in >>> current APIM 3.0.0 analytics. >>> Why do we want to move the reporting capabilities to admin users? >>> By moving report reporting capabilities to a separate portal (though >>> it's called a dashboard it seems like a report generation/download page) >>> are we going to include additional information in the reports? or is it >>> only to prevent showing restricted(access-controlled) API stats to >>> unintended publisher users? >>> Otherwise, We already present this information(visually) to publisher >>> users from the analytics dashboard, and the same data is available through >>> the REST APIs. So IMO restricting report generation capabilities to admin >>> users is not necessary. >>> >>> Regarding the report generation, Can't we render HTML pages as reports >>> and give users a print button to print or download it as PDF? In this way, >>> I think we will have more flexibility in styling and arranging the report >>> data. Basically providing a printable version of the widget (Graph/Table/ >>> pie chart etc,). >>> >> +1 for this. >> >>> >>> Thanks >>> ~KasunTe >>> >>> On Mon, Jan 6, 2020 at 10:12 PM Rukshan Premathunga >>> wrote: >>> Hi Fazlan, Can we know whats are the information admin users could include in the report? And is this parameter are selectable? ex: Tenant domain, API, Application, users information, etc. It also looks like the actual use case of this report/API is to provide monetization capabilities. Please verify if not. So are we providing the PDF generation capabilities to standard users, from existing widgets? Thanks and Regards On Mon, Jan 6, 2020 at 9:52 PM Harsha Kumara wrote: > Can we select range when generating the report? Also we need to > evaluate what are the common requirements and provide the capability to > generate the reports based on it. > > On Mon, Jan 6, 2020 at 5:47 PM Fazlan Nazeem wrote: > >> Hi all, >> >> We have been constantly getting requests from customers to have a >> proper PDF reporting mechanism where users can export analytics data in >> PDF >> format. Therefore we have implemented a prototype of this feature for the >> upcoming 3.1 release. >> >> The current prototype is implemented by exposing an MSF4J rest >> service which will generate a hit count report for a particular month, >> year >> combination. The month, year combination has to be passed as query params >> to the API. Attached herewith is a PDF report generated by this service. >> We >> are thinking of adding two more types of reports if time permits. >> Altogether this makes 3 types of reports which can be downloaded. >> >> 1) Request Summary >> 2) Throttle Summary >> 3) Fault summary >> >> The plan is to secure the service with tenant admin credentials. This >> means not all users who visit the analytics dashboard will be able to >> download the PDF report unless he/she is an admin. We are thinking of >> exposing a new dashboard with a single widget that takes the inputs >> (year, >> month) and downloads this report. The dashboard will be secured with >> admin >> role, resulting in only admin users being able to view this dashboard. >> The >> rationale behind this decision is not to expose analytics data of >> publisher >> access-controlled APIs to normal API publishers. >> >> Please provide your suggestions on any improvements or changes which >> can add value to this feature. >> >> -- >> Thanks & Regards, >> >> *Fazlan Nazeem | *Associate Technical Lead | WSO2 Inc >> Mobile : +94772338839 | fazl...@wso2.com >> >> >> > > -- > > *Harsha Kumara* > > Technical Lead, WSO2 Inc. > Mobile: +94775505618 > Email: hars...@wso2.coim > Blog: harshcreationz.blogspot.com > > GET INTEGRATION AGILE > Integration Agility for Digitally Driven Business >
Re: [Architecture] PDF Report Generation for APIM Analytics
It would be better if the header and footer are customizable in the generated report since customers might wish to add their logos, copyrights to the generated report. We can get required stuff ( ex: logo image of a given size, footer text etc ) as inputs and if not given fallback to defaults. On Mon, Jan 6, 2020 at 10:48 PM Harsha Kumara wrote: > > > On Mon, Jan 6, 2020 at 10:45 PM Kasun Thennakoon wrote: > >> Hi Fazlan, >> >> This analytics report looks much better than the reports generated in >> current APIM 3.0.0 analytics. >> Why do we want to move the reporting capabilities to admin users? >> By moving report reporting capabilities to a separate portal (though it's >> called a dashboard it seems like a report generation/download page) are we >> going to include additional information in the reports? or is it only to >> prevent showing restricted(access-controlled) API stats to >> unintended publisher users? >> Otherwise, We already present this information(visually) to publisher >> users from the analytics dashboard, and the same data is available through >> the REST APIs. So IMO restricting report generation capabilities to admin >> users is not necessary. >> >> Regarding the report generation, Can't we render HTML pages as reports >> and give users a print button to print or download it as PDF? In this way, >> I think we will have more flexibility in styling and arranging the report >> data. Basically providing a printable version of the widget (Graph/Table/ >> pie chart etc,). >> > +1 for this. > >> >> Thanks >> ~KasunTe >> >> On Mon, Jan 6, 2020 at 10:12 PM Rukshan Premathunga >> wrote: >> >>> Hi Fazlan, >>> >>> Can we know whats are the information admin users could include in the >>> report? And is this parameter are selectable? ex: Tenant domain, API, >>> Application, users information, etc. >>> It also looks like the actual use case of this report/API is to provide >>> monetization capabilities. Please verify if not. So are we providing the >>> PDF generation capabilities to standard users, from existing widgets? >>> >>> Thanks and Regards >>> >>> >>> >>> On Mon, Jan 6, 2020 at 9:52 PM Harsha Kumara wrote: >>> Can we select range when generating the report? Also we need to evaluate what are the common requirements and provide the capability to generate the reports based on it. On Mon, Jan 6, 2020 at 5:47 PM Fazlan Nazeem wrote: > Hi all, > > We have been constantly getting requests from customers to have a > proper PDF reporting mechanism where users can export analytics data in > PDF > format. Therefore we have implemented a prototype of this feature for the > upcoming 3.1 release. > > The current prototype is implemented by exposing an MSF4J rest service > which will generate a hit count report for a particular month, year > combination. The month, year combination has to be passed as query params > to the API. Attached herewith is a PDF report generated by this service. > We > are thinking of adding two more types of reports if time permits. > Altogether this makes 3 types of reports which can be downloaded. > > 1) Request Summary > 2) Throttle Summary > 3) Fault summary > > The plan is to secure the service with tenant admin credentials. This > means not all users who visit the analytics dashboard will be able to > download the PDF report unless he/she is an admin. We are thinking of > exposing a new dashboard with a single widget that takes the inputs (year, > month) and downloads this report. The dashboard will be secured with admin > role, resulting in only admin users being able to view this dashboard. The > rationale behind this decision is not to expose analytics data of > publisher > access-controlled APIs to normal API publishers. > > Please provide your suggestions on any improvements or changes which > can add value to this feature. > > -- > Thanks & Regards, > > *Fazlan Nazeem | *Associate Technical Lead | WSO2 Inc > Mobile : +94772338839 | fazl...@wso2.com > > > -- *Harsha Kumara* Technical Lead, WSO2 Inc. Mobile: +94775505618 Email: hars...@wso2.coim Blog: harshcreationz.blogspot.com GET INTEGRATION AGILE Integration Agility for Digitally Driven Business >>> >>> >>> -- >>> Rukshan C. Premathunga | Associate Technical Lead | WSO2 Inc. >>> (m) +94711822074 | (w) +94112145345 | Email: ruks...@wso2.com >>> GET INTEGRATION AGILE >>> Integration Agility for Digitally Driven Business >>> >> >> >> -- >> *Kasun Thennakoon* | Associate Technical Lead | WSO2 Inc. >> (m) +94 711661919 | (w) +94 11 214 5345 | (e) kasu...@wso2.com >> GET INTEGRATION AGILE >> Integration Agility for Digitally Driven Business >> > > > -- > > *Harsha Kumara* > > Technical Lead, WSO2 Inc. > Mobile: +94775505618 > Email: hars...@wso2.coim >
Re: [Architecture] PDF Report Generation for APIM Analytics
On Mon, Jan 6, 2020 at 10:45 PM Kasun Thennakoon wrote: > Hi Fazlan, > > This analytics report looks much better than the reports generated in > current APIM 3.0.0 analytics. > Why do we want to move the reporting capabilities to admin users? > By moving report reporting capabilities to a separate portal (though it's > called a dashboard it seems like a report generation/download page) are we > going to include additional information in the reports? or is it only to > prevent showing restricted(access-controlled) API stats to > unintended publisher users? > Otherwise, We already present this information(visually) to publisher > users from the analytics dashboard, and the same data is available through > the REST APIs. So IMO restricting report generation capabilities to admin > users is not necessary. > > Regarding the report generation, Can't we render HTML pages as reports and > give users a print button to print or download it as PDF? In this way, I > think we will have more flexibility in styling and arranging the report > data. Basically providing a printable version of the widget (Graph/Table/ > pie chart etc,). > +1 for this. > > Thanks > ~KasunTe > > On Mon, Jan 6, 2020 at 10:12 PM Rukshan Premathunga > wrote: > >> Hi Fazlan, >> >> Can we know whats are the information admin users could include in the >> report? And is this parameter are selectable? ex: Tenant domain, API, >> Application, users information, etc. >> It also looks like the actual use case of this report/API is to provide >> monetization capabilities. Please verify if not. So are we providing the >> PDF generation capabilities to standard users, from existing widgets? >> >> Thanks and Regards >> >> >> >> On Mon, Jan 6, 2020 at 9:52 PM Harsha Kumara wrote: >> >>> Can we select range when generating the report? Also we need to evaluate >>> what are the common requirements and provide the capability to generate the >>> reports based on it. >>> >>> On Mon, Jan 6, 2020 at 5:47 PM Fazlan Nazeem wrote: >>> Hi all, We have been constantly getting requests from customers to have a proper PDF reporting mechanism where users can export analytics data in PDF format. Therefore we have implemented a prototype of this feature for the upcoming 3.1 release. The current prototype is implemented by exposing an MSF4J rest service which will generate a hit count report for a particular month, year combination. The month, year combination has to be passed as query params to the API. Attached herewith is a PDF report generated by this service. We are thinking of adding two more types of reports if time permits. Altogether this makes 3 types of reports which can be downloaded. 1) Request Summary 2) Throttle Summary 3) Fault summary The plan is to secure the service with tenant admin credentials. This means not all users who visit the analytics dashboard will be able to download the PDF report unless he/she is an admin. We are thinking of exposing a new dashboard with a single widget that takes the inputs (year, month) and downloads this report. The dashboard will be secured with admin role, resulting in only admin users being able to view this dashboard. The rationale behind this decision is not to expose analytics data of publisher access-controlled APIs to normal API publishers. Please provide your suggestions on any improvements or changes which can add value to this feature. -- Thanks & Regards, *Fazlan Nazeem | *Associate Technical Lead | WSO2 Inc Mobile : +94772338839 | fazl...@wso2.com >>> >>> -- >>> >>> *Harsha Kumara* >>> >>> Technical Lead, WSO2 Inc. >>> Mobile: +94775505618 >>> Email: hars...@wso2.coim >>> Blog: harshcreationz.blogspot.com >>> >>> GET INTEGRATION AGILE >>> Integration Agility for Digitally Driven Business >>> >> >> >> -- >> Rukshan C. Premathunga | Associate Technical Lead | WSO2 Inc. >> (m) +94711822074 | (w) +94112145345 | Email: ruks...@wso2.com >> GET INTEGRATION AGILE >> Integration Agility for Digitally Driven Business >> > > > -- > *Kasun Thennakoon* | Associate Technical Lead | WSO2 Inc. > (m) +94 711661919 | (w) +94 11 214 5345 | (e) kasu...@wso2.com > GET INTEGRATION AGILE > Integration Agility for Digitally Driven Business > -- *Harsha Kumara* Technical Lead, WSO2 Inc. Mobile: +94775505618 Email: hars...@wso2.coim Blog: harshcreationz.blogspot.com GET INTEGRATION AGILE Integration Agility for Digitally Driven Business ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] PDF Report Generation for APIM Analytics
Hi Fazlan, This analytics report looks much better than the reports generated in current APIM 3.0.0 analytics. Why do we want to move the reporting capabilities to admin users? By moving report reporting capabilities to a separate portal (though it's called a dashboard it seems like a report generation/download page) are we going to include additional information in the reports? or is it only to prevent showing restricted(access-controlled) API stats to unintended publisher users? Otherwise, We already present this information(visually) to publisher users from the analytics dashboard, and the same data is available through the REST APIs. So IMO restricting report generation capabilities to admin users is not necessary. Regarding the report generation, Can't we render HTML pages as reports and give users a print button to print or download it as PDF? In this way, I think we will have more flexibility in styling and arranging the report data. Basically providing a printable version of the widget (Graph/Table/ pie chart etc,). Thanks ~KasunTe On Mon, Jan 6, 2020 at 10:12 PM Rukshan Premathunga wrote: > Hi Fazlan, > > Can we know whats are the information admin users could include in the > report? And is this parameter are selectable? ex: Tenant domain, API, > Application, users information, etc. > It also looks like the actual use case of this report/API is to provide > monetization capabilities. Please verify if not. So are we providing the > PDF generation capabilities to standard users, from existing widgets? > > Thanks and Regards > > > > On Mon, Jan 6, 2020 at 9:52 PM Harsha Kumara wrote: > >> Can we select range when generating the report? Also we need to evaluate >> what are the common requirements and provide the capability to generate the >> reports based on it. >> >> On Mon, Jan 6, 2020 at 5:47 PM Fazlan Nazeem wrote: >> >>> Hi all, >>> >>> We have been constantly getting requests from customers to have a proper >>> PDF reporting mechanism where users can export analytics data in PDF >>> format. Therefore we have implemented a prototype of this feature for the >>> upcoming 3.1 release. >>> >>> The current prototype is implemented by exposing an MSF4J rest service >>> which will generate a hit count report for a particular month, year >>> combination. The month, year combination has to be passed as query params >>> to the API. Attached herewith is a PDF report generated by this service. We >>> are thinking of adding two more types of reports if time permits. >>> Altogether this makes 3 types of reports which can be downloaded. >>> >>> 1) Request Summary >>> 2) Throttle Summary >>> 3) Fault summary >>> >>> The plan is to secure the service with tenant admin credentials. This >>> means not all users who visit the analytics dashboard will be able to >>> download the PDF report unless he/she is an admin. We are thinking of >>> exposing a new dashboard with a single widget that takes the inputs (year, >>> month) and downloads this report. The dashboard will be secured with admin >>> role, resulting in only admin users being able to view this dashboard. The >>> rationale behind this decision is not to expose analytics data of publisher >>> access-controlled APIs to normal API publishers. >>> >>> Please provide your suggestions on any improvements or changes which can >>> add value to this feature. >>> >>> -- >>> Thanks & Regards, >>> >>> *Fazlan Nazeem | *Associate Technical Lead | WSO2 Inc >>> Mobile : +94772338839 | fazl...@wso2.com >>> >>> >>> >> >> -- >> >> *Harsha Kumara* >> >> Technical Lead, WSO2 Inc. >> Mobile: +94775505618 >> Email: hars...@wso2.coim >> Blog: harshcreationz.blogspot.com >> >> GET INTEGRATION AGILE >> Integration Agility for Digitally Driven Business >> > > > -- > Rukshan C. Premathunga | Associate Technical Lead | WSO2 Inc. > (m) +94711822074 | (w) +94112145345 | Email: ruks...@wso2.com > GET INTEGRATION AGILE > Integration Agility for Digitally Driven Business > -- *Kasun Thennakoon* | Associate Technical Lead | WSO2 Inc. (m) +94 711661919 | (w) +94 11 214 5345 | (e) kasu...@wso2.com GET INTEGRATION AGILE Integration Agility for Digitally Driven Business ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] PDF Report Generation for APIM Analytics
Can we select range when generating the report? Also we need to evaluate what are the common requirements and provide the capability to generate the reports based on it. On Mon, Jan 6, 2020 at 5:47 PM Fazlan Nazeem wrote: > Hi all, > > We have been constantly getting requests from customers to have a proper > PDF reporting mechanism where users can export analytics data in PDF > format. Therefore we have implemented a prototype of this feature for the > upcoming 3.1 release. > > The current prototype is implemented by exposing an MSF4J rest service > which will generate a hit count report for a particular month, year > combination. The month, year combination has to be passed as query params > to the API. Attached herewith is a PDF report generated by this service. We > are thinking of adding two more types of reports if time permits. > Altogether this makes 3 types of reports which can be downloaded. > > 1) Request Summary > 2) Throttle Summary > 3) Fault summary > > The plan is to secure the service with tenant admin credentials. This > means not all users who visit the analytics dashboard will be able to > download the PDF report unless he/she is an admin. We are thinking of > exposing a new dashboard with a single widget that takes the inputs (year, > month) and downloads this report. The dashboard will be secured with admin > role, resulting in only admin users being able to view this dashboard. The > rationale behind this decision is not to expose analytics data of publisher > access-controlled APIs to normal API publishers. > > Please provide your suggestions on any improvements or changes which can > add value to this feature. > > -- > Thanks & Regards, > > *Fazlan Nazeem | *Associate Technical Lead | WSO2 Inc > Mobile : +94772338839 | fazl...@wso2.com > > > -- *Harsha Kumara* Technical Lead, WSO2 Inc. Mobile: +94775505618 Email: hars...@wso2.coim Blog: harshcreationz.blogspot.com GET INTEGRATION AGILE Integration Agility for Digitally Driven Business ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] PDF Report Generation for APIM Analytics
Hi all, We have been constantly getting requests from customers to have a proper PDF reporting mechanism where users can export analytics data in PDF format. Therefore we have implemented a prototype of this feature for the upcoming 3.1 release. The current prototype is implemented by exposing an MSF4J rest service which will generate a hit count report for a particular month, year combination. The month, year combination has to be passed as query params to the API. Attached herewith is a PDF report generated by this service. We are thinking of adding two more types of reports if time permits. Altogether this makes 3 types of reports which can be downloaded. 1) Request Summary 2) Throttle Summary 3) Fault summary The plan is to secure the service with tenant admin credentials. This means not all users who visit the analytics dashboard will be able to download the PDF report unless he/she is an admin. We are thinking of exposing a new dashboard with a single widget that takes the inputs (year, month) and downloads this report. The dashboard will be secured with admin role, resulting in only admin users being able to view this dashboard. The rationale behind this decision is not to expose analytics data of publisher access-controlled APIs to normal API publishers. Please provide your suggestions on any improvements or changes which can add value to this feature. -- Thanks & Regards, *Fazlan Nazeem | *Associate Technical Lead | WSO2 Inc Mobile : +94772338839 | fazl...@wso2.com report.pdf Description: Adobe PDF document ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
