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 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 >>> >>> >>
