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.
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. > 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/ > <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] > <mailto:[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] > <mailto:[email protected]>> wrote: > Hi Isuru & Suresh, > > Few concerns I have are, > Existing login implementation is a form submission and a server rendered > html. And it's session based. > 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] > <mailto:[email protected]>> wrote: > Hi Dinuka, > > On Mon, Apr 6, 2020 at 3:11 AM Dinuka Desilva <[email protected] > <mailto:[email protected]>> wrote: > > > On Mon, 6 Apr 2020, 06:36 Suresh Marru, <[email protected] > <mailto:[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/ > <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] >> <mailto:[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 >
smime.p7s
Description: S/MIME cryptographic signature
