I have a public website running from an eXist app. I am now developing an interface for logged in users to edit certain documents through HTML forms and AJAX. I've set up a module in eXist to receive AJAX POST requests through the eXist REST interface (ie. http://www.example.com/exist/rest/db/myapp/api/myxquery.xql). However this module does not seem to be aware of the fact that the user is already logged in!
How do I get the REST module to use the session/authentication of the logged in user?
Am I required to store the user/password in the browser to pass with each REST API request?
If this is not the preferred model for passing data from the browser under user/password, what is eXist's recommended solution?
Many thanks in advance.
(A variation on this question was asked two years ago but received no solutions.)
In order to use the REST-API from existdb you can only authenticate each request using HTTP Basic Authentication. Also mentioned in the question you referenced.
If you decide to handle AJAX request in your app's controller.xql you will need to:
Add routes for your AJAX requests to the controller
Make sure you call login:set-user for the user session to be picked up
Make sure the AJAX request sends the cookie:
For instance, the fetch function will send the authorisation cookie
only if send-authorization is true.
Look at the output-method and serialization settings, since you will likely want to respond in JSON-format. useful blog post about this
Related
I am curious if anyone has a solution to this unique situation as I have a solution currently, though I feel it is not the most optimal.
The Situation.
I have built an MVC style web application that talks to a web API through http (authenticating via JWT). My web application is secured by appending authorization to its view controllers and redirecting to a Microsoft login endpoint - then directing back to the view where whichever given controller/function handles the request, connects to the API, appends data to the view, etc.
Preferably I would like to use JQuery/Ajax to submit http requests client-side and update a given view with whatever data the user may wish to see relative to the webpage they're on. This way I could control exactly what the user should see landing on the page any which way and submitting requests from web app to API. Also would enable better continuity between requests as there isn't actually a full refresh of the view. All in all it is my line of thought that this execution would lead to a nice user experience.
The Problem.
So the big issue that I have had to circumvent is CORS Policy. I initially attempted to use JS just as I said above but requests would be redirected to the login endpoint and blocked due to there being no CORS header appended to the request.
'So include a policy in your application and append an authorized header to your Ajax outgoing request' you might say, well... you cannot override CORS security around Microsoft's login endpoint.
My Solution.
What I have done simply instead is create HTML Forms around fields the user would pick and chose to specify what data they wanted from the API. Then carry over input data to the returned view via 'ViewData'
and using razor pages of course I can actually initialize JS variables via C# input.
Side Note
I use JS to transform the API data into graphs for the user to see. I am doing this with a JavaScript Library.
My Question to you.
This all leads me to ask then, is there a way to dynamically update a view without using JS? I require a method that can hit the login redirect without being blocked because the request initiated client-side.
Every solution I am aware in some way, shape, or form utilizes JS to make the request. So I am at a loss for how to truly get the functionality I am after without having my requests get blocked due to CORS Policy.
Thanks in advance y'all.
I have more conteptual question, how exactly should I handle social login in my project.
The use case is that I would like to allow user to login with Facebook, and keep on my backend information about this user (email, firstname, lastname)
I have some proposal Flow, but I'm not sure if it's a proper approach.
Let's say that I have application architecture as above. Now I would like to explain step-by-step full success flow.
Client (Vue application) make a call to AuthProvider (Facebook)
AuthProvider returns access_token
Client after reciving access_token make a call to backend endpoint like /fb_profile with access_token and userID (?)
Backend make a call to AuthProvider to check if given by client access_token is valid or not.
AuthProvider returns information about user. Backend after getting information about user, save it to database and generate new JWT token
Backend returns generated token to user
Now my question is - Is this good approach? Or should i handle it in other way? Like keep more logic to backend part? Instead of make a call to Facebook from Client, maybe should I make a call to backend, and backend make a call to Facebook?
You seem to be on right track. There could me many ways to do the same thing, here is the way which is working for me using vue/laravel/passport/socialite/github.
Trigger redirect in controller from frontend,
Provider(here github app) is triggered in browser with its url using client id/app name saved in back end config/env. Fill out your login details
It will redirect as created in provider and configured in backend-> show it on frontend, in my case its
http://localhost:8080/authorize/github/callback
From frontend now trigger callback in controller, it will check if user details already exist and will insert if its first time user as per logic. Then it will send back access_token to frontend which can be used in frontend for all the operations
DB
The above will be the sequence of the request flow ( same as yours ).
This would be the standard practice we used to integrate with Facebook. In this case, I strictly advise you to use the JavaScript SDK for Facebook.
Refer below link in case if you run into the following issue:
Vuejs component wait for facebook sdk to load
Maybe this is not possible...
I have one site, we'll call it club.com
And I have another site called store.com
I have control of both domains. club.com is powered by a Django project, and store.com is a shopify site.
If you're a member of club.com, you get a discount on store.com
We want to do it so that integration is seamless. No need to enter your club.com credentials to store.com, we want the page to do that for you.
How do I implement this?
I already tried simply putting an ajax call on store.com pointing to club.com, and it seems to work with one exception: The browser is not sending the proper cookies along with the request, so when club.com gets this ajax request it can't authenticate it.
You should consider OAuth2 to achieve what you need.
i am using JSONP for cross domain ajax. It works perfecly. My doubt is that, is there any security issues while using jsonp?
EDIT
Just saw that there is already the same question: (Is JSONP safe to use?)
well you need to keep in mind that if you use 'jsonp' any external site could also call this script and get the result of you response.
the security problem occurs when the actions or responses are limited in some kind to a login of the user. e.g. if you return certain informations only if the user is logge
if you have information you only send to the client when the user is logged in or if there are certain actions only allowed when the user is logged in it is . so if a user is logged in and browsing to another page, this page could theoretically do jsonp requests for that user.
My question is that suppose, in my web app, I use ajax to call upon methods on the server side, isn't it creating a security hole in the app? Like, say I have an option for the user to deactivate the account, which can be done by clicking a button. This is done via Ajax.
So, can't a hacker send a request to the server to deactivate the account instead of the user?
HELP!!!
My question is that suppose, in my web app, I use ajax to call upon methods on the server side, isn't it creating a security hole in the app?
From a security perspective, there is no difference between an HTTP request that involves JavaScript and one which doesn't (e.g. that uses a regular form, or is handcrafted).
… but you can't call methods from the client, you can only make requests to URIs. The server might cause a method to be called based on receiving a request to a specific URI.
So, can't a hacker send a request to the server to deactivate the account instead of the user?
They could, which is why you need (trustworthy) authentication / authorisation and CSRF protection (just like you would for a request to disable an account that didn't involve Ajax).
This is not a problem with AJAX alone, but with any arbitrary HTTP request that wants to authenticate/maintain a session. The user needs to be authenticated in some way in order to make requests, this is usually done with cookies. Using AJAX does not make the matter any worse though because it is still a HTTP request.
Authentication alone is not enough though, someone could always be listening on the wire and capture the authentication cookie, and thus get hold of the session - "become you". The only solution here is to encrypt the connection on a lower OSI layer level (using SSL/TLS). This is why you should always use SSL when it comes to authentication.
This Ruby on Rails security guide has a great explanation on how to deal with AJAX requests that could be potentially exploited. It's not specific to RoR so the concepts can apply to any platform.
One way to reduce the risk of cross site requests is to use POST for actions that modify or delete data.