On Thu, 9 Apr 2020, 01:20 Dinuka Desilva, <[email protected]> wrote:
> > Hi Marcus, > > On Wed, Apr 8, 2020 at 3:22 AM Dinuka Desilva <[email protected]> > wrote: > >> Hi Marcus, >> >> Thanks lot for your response >> >> On Wed, 8 Apr 2020, 03:13 Christie, Marcus Aaron, <[email protected]> >> wrote: >> >>> Hi Dinuka, >>> >>> There is a /auth/login-desktop/ view in airavata-django-portal that has >>> the user login and then exposes the access token, etc. on the URL as query >>> parameters. This is what SEAGrid Desktop uses to login. You could start >>> with that. >>> >> Let me check this out. >> > I tried this out. And some more questions > > 1) http://localhost:8000/auth/login-desktop from this upon successful > login, it's redirected to http://localhost:8000/auth/login-desktop > /auth/login-desktop-success/ > <https://testdrive.airavata.org/auth/login-desktop-success/?> with status, > code, refresh_code, valid_time and username as query parameters. But, a > custom redirection url cannot be defined. (I couldn't find a way) > > 2) Once above is executed, I ended up with the issue I have mentioned on > another email thread [1]. I tried three times and it happened right after > "login-desktop" request. > > 3) I tried this on https://testdrive.airavata.org/ also it has no issues. > But, still I want to get the redirection happen to a custom url that I > could specify. Could you help me figure out the right settings for that. > > 4) From the "login-desktop" requests, I get only the status, code, > refresh_code, valid_time and username. Using these, how can I obtain the > access token. Is there an api for that? I found only this > "refreshed-token-desktop". But, still it returns no tokens in the response. > > >>> That's maybe not the best way to do it, so I'm open to suggestions. I >>> think ideally the desktop client would have its own client id and secret >>> and log users in directly. >>> >> I would like this too. How can I obtain a client id and a secret? >> >>> >>> On Apr 7, 2020, at 11:42 AM, Dinuka Desilva <[email protected]> >>> wrote: >>> >>> Hi Isuru, >>> >>> The django portal front end is not completely separated from backend and >>> its being managed via django views. So, actually both api and front end are >>> running on the same server. Consequently, any session or cookie variables >>> are accessible across. >>> >>> But, when comes to the electron app, it's UI is separate (unless it uses >>> a deployed url). So, for the authentication a redirection has to happen >>> from the electron app to the django app and upon success, it has to be >>> redirected back to the electron app. But, the thing is no cookies or >>> sessions or any variables are passed back. >>> >>> Following is how I got it redirected. Electron can be run on just file >>> system also. But, since redirecting to file:// is not supported, I put up a >>> server (ports to be changed etc.) >>> >>> https://testdrive.airavata.org/auth/login?next=http://localhost:8080/ >>> >>> If I could get the right approach I could go ahead. I'm kind of blocked >>> here. >>> >>> Regards, >>> Dinuka >>> >>> >>> >>> On Tue, Apr 7, 2020 at 8:41 AM Isuru Ranawaka <[email protected]> >>> wrote: >>> >>>> Hi Dinuka, >>>> >>>> Adding Marcus to the thread. He may also have good ideas on this. >>>> >>>> On Mon, Apr 6, 2020 at 6:03 PM Dinuka Desilva < >>>> [email protected]> wrote: >>>> >>>>> Hi Isuru & Suresh, >>>>> >>>>> Few concerns I have are, >>>>> >>>>> 1. Existing login implementation is a form submission and a server >>>>> rendered html. And it's session based. >>>>> 2. The endpoints are also session based and goes through CSRF >>>>> verification. >>>>> >>>>> So, I'm not quite seeing any clear direction than electron app >>>>> directly accessing the app by url. Any advice is much appreciated. >>>>> >>>> >>>> >>>> >>>> >>>> what I have understood from your concerns, is that you are worrying >>>> about session management between the backend server and the frontend. >>>> Basically, where to decouple frontend view management logic from the >>>> frontend server API management layer. Is that your concern? Can you >>>> explain a bit more about how your electron app design decouples view >>>> management components (including HTML, CSS, JS) from the server access API >>>> layer?. Does it have any state management mechanism? >>>> >>>> Anyhow, we need CSRF verifications at least for authentication >>>> requests between frontend and backend. But, there should be a CSRF >>>> verification process between browser requests and frontend server. >>>> >>>> >>>> thanks >>>> Isuru >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> Regards, >>>>> Dinuka >>>>> >>>>> On Mon, Apr 6, 2020 at 6:31 PM Isuru Ranawaka <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Dinuka, >>>>>> >>>>>> On Mon, Apr 6, 2020 at 3:11 AM Dinuka Desilva < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, 6 Apr 2020, 06:36 Suresh Marru, <[email protected]> wrote: >>>>>>> >>>>>>>> Hi Dinuka, >>>>>>>> >>>>>>>> We have not successfully used Thrift generated JS previously (its >>>>>>>> possible but do not have that experience within Airavata). Django >>>>>>>> portal >>>>>>>> uses the python generated code and exposes them as REST API’s using >>>>>>>> DRF ( >>>>>>>> https://www.django-rest-framework.org/). The Vue.js UI components >>>>>>>> communicate to these REST API’s. I wonder if you can have electronJS >>>>>>>> talk >>>>>>>> to the same API’s instead of directly to Airavata API. >>>>>>>> >>>>>>> >>>>>>> Yes. Since airavata APIs doesn't have any authentication or >>>>>>> authorization layer, I have to use the Django API. My only worry is >>>>>>> then >>>>>>> this become only a copy of the same application. Is that the only >>>>>>> purpose >>>>>>> of this? >>>>>>> >>>>>>> Airavata APIs do not have an authentication layer. But it has an >>>>>> authorization layer. You can refer to AiravataAPIServer class there it >>>>>> engages a security interceptor for authorization. Anyhow, I guess using >>>>>> same APIs that used by Vue.js will enhanced code reusability otherwise >>>>>> there will be two code bases for the same functionality. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Also, we would like to move from Thrift to Protobuf and gRPC. I >>>>>>>> wonder if REST support can be more seamless once the migration is done. >>>>>>>> >>>>>>>> Suresh >>>>>>>> >>>>>>>> On Apr 5, 2020, at 4:17 PM, Dinuka Desilva < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I'm trying to generate the es6 client stub for airavata api using >>>>>>>> the following script. >>>>>>>> >>>>>>>> thrift -r --gen js:es6 >>>>>>>> ../../airavata/thrift-interface-descriptions/airavata-apis/airavata_api.thrift >>>>>>>> >>>>>>>> >>>>>>>> But, I'm not getting it correctly I guess. I'm getting a list of >>>>>>>> files in a folder called gen-js. Instead what I need is a structured >>>>>>>> code >>>>>>>> as there in the airavata-django-portal. >>>>>>>> >>>>>>>> I'm also not sure whether what's on the portal is a generated code. >>>>>>>> Please advise. >>>>>>>> >>>>>>>> <Screenshot 2020-04-06 at 1.42.41 AM.png> >>>>>>>> >>>>>>>> Can you help me? >>>>>>>> >>>>>>>> *References* > > [1] > https://lists.apache.org/thread.html/r31240dc6041c1af5fb2c9a0ca024808aece4235180dd77edd5a6ddd9%40%3Cdev.airavata.apache.org%3E > > >> >>>>>>>> Regards, >>>>>>>> Dinuka >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> -- >>>>>> Research Software Engineer >>>>>> Indiana University, IN >>>>>> >>>>>> >>>> >>>> -- >>>> Research Software Engineer >>>> Indiana University, IN >>>> >>>> >>> >>>
