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. > > 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? >>>>>> >>>>>> Regards, >>>>>> Dinuka >>>>>> >>>>>> >>>>>> >>>> >>>> -- >>>> Research Software Engineer >>>> Indiana University, IN >>>> >>>> >> >> -- >> Research Software Engineer >> Indiana University, IN >> >> >
