Add API with browser session #20613
Add API with browser session #20613
Conversation
|
I don't think this is correct, the API shouldn't use a sessioner, The API shouldn't be accessible via some sort of CSRF token. Just create a user token for this purpose. |
GiteaBot
added
the
lgtm/need 2
|
Some background (quoted from another comment) I think it's worth to write some design document to clarify the architecture, to make the roadmap clear. Maybe one day in the future enough people want to make the API use session again, no matter what happens, it really needs to be discussed and make a consensus and have a document. For me, I also think it's not fine to make API use session again at the moment, no benefit. Usually, the web backend and api backend is different. And there were some PRs to decouple the API endpoints from the web. Some backgrounds: |
|
My current use is to add javascript to the Gitea interface, get some information through the API, and display it in the original interface, such as report information |
No idea what info you're accessing, but it might be possible that you could access it via the current web API's. |
TBH, no idea from my side. Making the API use session (correctly) might be a solution. That's what I meant I think you can describe your requirements with more details and examples, and ping |
|
The data I need to organize, the format output by the original UI cannot be used directly. For example, I want to organize the issue I reported in the past week output my format. My browser has already been authenticated, and I have to re-authenticate it when I use AJAX to read it. which doesn't make sense |
|
To give another example, for example, I have added a desktop notification program information to the footer.tmpl through the API, if there is no browser session, it will not be able to get 'Notification' in window && Notification.requestPermission().then(function(permission) {
if ('granted' == permission) {
const channel = new BroadcastChannel('logout-notify'), notificationfunc = function() {
$.getJSON('/api/v1/notifications?limit=10', {_csrf: config.csrfToken}).then(function(response) {
if (response.length) {
$('.notification_count').text(response.length);
$('.notification_count.hidden').removeClass('hidden');
const notificationed = localStorage.getItem('notificationed');
response.reverse();
$(response).each(function(_, data) {
if (!notificationed || notificationed && data.updated_at > notificationed) {
localStorage.setItem('notificationed', data.updated_at);
new Notification(data.repository.full_name +'#'+ data.subject.html_url.slice(data.subject.html_url.lastIndexOf('/') + 1) +' '+ data.subject.state, {
icon: window.config.appUrl + 'assets/img/favicon.png',
body: data.subject.title,
tag: 'Gitea'+ data.id
}).onclick = function(e) {
e.preventDefault();
window.open(data.subject.latest_comment_html_url || data.subject.html_url);
};
}
});
}
});
}, startnotification = function() {
if (!notificationtimer)
notificationtimer = setInterval(notificationfunc, 60000);
};
channel.onmessage = function() {
clearTimeout(notificationtimer);
notificationtimer = 0;
};
channel.postMessage('');
startnotification();
// notificationfunc();
window.onfocus = function() {
startnotification();
channel.postMessage('');
};
}
}); |
Create a new router for web routers. |
|
Porting the same code from API to Web Router? Or from web router call API functions directly? |
The function maybe reused. |
|
Adding |
|
Error details: An error occurred: |
|
Yes, the contexts are different from Web and API routers. |
|
Why can't we use the existing API and need to write another web router? what else can this API do? |
The design to split UI rourters from API make things more flexible. Here is the pros,
|
It only means that "do not put WebUI-only routers to API routers", it doesn't answer why "the API shouldn't be accessed by session". "making the API can be accessed by session" and "keeping WebUI-only routers in web routers" can also have these Pros. |
lafriks
added
the
status/blocked
|
It may have security implications if API can be called directly using user session and without CSRF token |
Added |
Once API supports session, they could be used from UI with no error. Then you have to write some documents to prevent users to send PRs to do that. So I think making it impossible technically is reasonable. |
Closes #20585