Does grid computing continue when the user is not logged in - for instance, on an educational system, where students must log in, when the log out, does the cpu continue the cloud computing? Or in another instance, if I use my home computer for something like superdonate.com, does the processor still go if I log out?
It depends on the client and how it is set up. But I think most clients continue to work when you log off.
The whole purpose is to use the computer when it is idle after all.
Your question is very generic. Technically, if you have delegation of credential, yes. In Globus you delegate authentication credential to a third part, and it will continue acting on your behalf even if you "log out".
Related
I have a working monolith application (deployed in a container), for which I want to add notifications feature as a separate microservice.
I'm planning for the monolith to emit events to a message bus (RabbitMQ) where they will be received by the new service, which will send the notification to user. In order to compose a notification, it will need other information about the user from the monolit, so it will call monolith's REST API in order to obtain it.
The problem is, that access to the monolith's API requires authentication in form of a token. I was thinking of:
using the secret from the monolith to issue a never-expiring token - I don't think this is a great idea from the security perspective, and also I know that sometimes the keys rotate in which case the token would became invalid eventually anyway
using the message bus to retrieve the information - this does not seem a good idea either as the asynchrony would make it very complicated
providing all the info the notification service needs in the event - this would make them more coupled together, and moreover, I plan to also send notifications based on the state on the monolith not triggered by an event
removing the authentication from the monolith and implementing it differently (not sure how yet)
My question is, what are some of the good ways this kind of problem can be solved, and also, having just started learning about microservices, is what I am trying to do right in the first place?
When dealing with internal security you should always consider the deployment and how the APIs are exposed to the outside world, an API gateway might be used to simply make it impossible to access internal APIs. In that case, a fixed token might be good enough to ensure that the client is authorized.
In general, though, I would suggest looking into OAuth2 or a JWT-based solution as it helps to validate the identities of the calling system as well as their access grants.
As for your architecture doubts, you need to consider the following scenarios when building out the solution:
The remote call can fail, at any time for unknown reasons, as such you shouldn't acknowledge the notification event until you're certain that the notification has been processed successfully.
As you've mentioned RabbitMQ, you should aim to keep the notification queue as small as possible, to that effect, a cache that contains the user details might help speed things along (and help you reduce the chance of failure due to the external system not being available).
If your application sends a lot of notifications to potentially millions of different users, you could consider having a read-only database replica of the users which is accessible to the notification service, and directly read from the database cluster in batches. This reduces the load on the monolith and shift it to the database layer
Hello fellow developers,
I recently stumbled upon the Application Log and find it to be quite handy. Now I am wondering, from a best practice perspective, what are some use cases for utilizing the Application Log vs. normal messages / class based exceptions?
Normally application log is used when end-user need not be informed of this information. Application log complements the normal messages and class based exceptions but not completely replace them.
Imagine a situation, there is an issue with data on a background processing. If a developer want to see what is the data that was being processed (after it is processed), it will be difficult. A developer can thus write some data to application log based on his gut if there is a possibility of failure.
Normally, this application logging is controlled by some user parameters and also the granularity of the data that is being stored in application log.
Hope this helps.
The application log comes in handy to
store messages. Interactive messages and exceptions are lost after the user clicks them away. The application log stores that information for longer periods of time.
log background processes. These have no direct means to inform a user because there is no user, only some other process that triggered the batch.
provide additional details. Interactive messages are usually minimized to not spam the user with too many popups. The application log can provide additional aspects and side infos to accompany the main result.
log "undercurrents". If a reuse component is unsure what level of detail its consumer wants, it can write an application log with high level of detail that the consumer later can consume or not, as desired.
It is not appropriate when
you want to process the logged details in an automatic way. Application logs are for display to the end user. Application processing should store or hand over data in a more appropriate format.
you need to process vast amounts of data. Writing the application log is fast, but takes time for the database roundtrips, such that large numbers of records can slow down the actual application too much.
you need to store sensitive data. Application logs are secured with authorization checks, but still they may not be the appropriate place for really sensitive information.
I'm using grails 1.3.5 and I need to automatically log out users from my app when they close their browser or all tabs in which my app is opened.
While there is no particularly reliable way to do this (in any web framework, not just Grails), there are some rather hacky ways you can get close to this, though there are some massive tradeoffs.
In general, since you have a default session timeout, the user will be logged out (in general) when their session expires due to not receiving a request associated with their session. This behavior can be changed depending on your security environment, but we'll assume you are using (sensible) defaults.
This session expiration logout can be abused to mimic logging them out when they have no windows/tabs with your application open in them. To do this, you could have a small piece of JavaScript that continually "pings" your server at whatever interval you specify to keep the session "alive" and keep them logged in. How tight you set these pings is a tradeoff between the load on your server and the window of time where they could close their browser and re-open it and still stay logged in.
Like I said, this is very hacky, but it's functional.
In my app (iOS) data upload (http post) sometimes fails (timeout) on bad networks (EDGE).
What is the best strategy for retrying?
Should i retry immediatly or should i wait for "better" network conditions?
How could that be achieved?
There are many ways to handle this, but which you choose very much depends on your application, and how critical the data you're posting is:
Assuming you're doing this in the background (asynchronously), just keep retrying until it works - maybe up to a maximum number of times.
Inform the user and ask them if they want to try again (let them know they need a network connection).
Store a cache of all un-transmitted data and try again after a period of time, or on app restart or when the app is backgrounded.
There's no best strategy - it all depends on the use case for your app.
I would suggest having first try as normal but when it fails, show a UIAlertView with message some thing like: "Couldn't connect to servers, do you want to try again". Place Yes and No button. And when user taps YES, give it another try.
Hello i have a question,
i write a requirement specification.
there is a system, where more than one person interacts with,
and i want to describe what happens when one person quits the interaction.
I don't know how exactly a mulituser systems works,
i guess the system creates an instance (?), and when the user finished it get closed again?
but the system as such still runs (for sure).
how can i discribe that ... issue correctly? ( does it work like i guessed?)
thanks in davance
I'd say that the system listen on two different things :
a message (interaction) from one of the connected users
a login message from a new user
This behavior is parametrized by the number of connected users. In the limit case where all connected users disconnect, the system does not wait anything from connected users, but keep listening on new connections.