I have a VB ASP.NET aplication which at some point it has to send some emails (using System.Net.Mail).
I want to send them in background and once the sending finishes get some notification to know if the email was sent correctly or not (alert() the user). I tried to use SendAsync email, the problem is that in that way it freezes the UI, I also tried to encapsulate all the sending email method into a thread but after that the Httpcontext.current object is always null so I can't show the alert().
I have tried to search a solution around Stackoverflow but without any luck....
Related
I am currently using Refit and have been handling my auth stuff in an AuthenticationService where I set my Refit settings to have AuthorizationHeaderValueGetter use my AuthenticationService.GetAuthenticationToken() to get my access_token. The logic inside my GetAuthenticationToken() method checks the token expiration and will attempt to use the refresh_token to get a new access_token if it is expired. If all fails it will show the login screen of my app.
My test group has reported that they are asked to login frequently so I feel like there is something not working optimally in my design.
Am I doing too much in the AuthorizationHeaderValueGetter?
Should I be doing this in a DelegatingHandler where I can resubmit the api request after getting a new access_token?
I have background fetch stuff that happens in my app so I need to be able to have the refresh_token automatically get a new access_token during the background process.
Ok, so I stumbled upon my issue. The sequence that created this problem in the wild is:
app is backgrounded after user is logged in and using app normally
the access_token expires while in the background
background fetch runs getting a new access_token and refresh_token and doing normal work
user foregrounds the app
The problem was that the new token info was not persisted when the background fetch ran. So, when the user foregrounded the app my ResumeManager checked IsUserLoggedIn which used the old token info, so it would see an expired access_token and tried to use an already consumed refresh_token since it was used in the background fetch. This resulted in an invalid_grant and the login screen was displayed.
The good news is, easy fix and my logic is fine, also it appears doing all this in the AuthorizationHeaderValueGetter is not a problem.
Hopefully this info helps someone else even though it was more a careless mistake than anything else.
I have a Blazor server application (great) with a Razor page login form (absolute pain in my backside).
Upon submitting the login form, in the PageModel class I have an OnPostAsync method which calls upon my API to sign in and obtain an auth token, but obviously there is an element of delay to this (quite bad in my case at the moment). As it is, my page shows almost no indication that it is doing anything at all after pressing login, whilst the API is being contacted the page sits there like the submit button hasn't even been pressed, which is obviously very bad for users because the first thing they will do is mash the submit button until they get a visual response (as I probably would to be fair).
How on earth do I do this in a Razor page? I've tried this and this, neither have worked. At the moment I don't particularly care what is shown or done, I just want it to do SOMETHING. The perfect solution for me is disabling the form and/or overlaying something to show that it's busy, but I'd take a basic "Loading..." message somewhere.
Is there any way of doing this?
It seems that it simply isn't possible to do with a Razor page in a Blazor server application, because there is nothing to update the UI, it's not like a Blazor component where there is a SignalR connection kept active between the server and the client. In the case of the login page, the page is served to the client and the connection is then severed, so the next action that occurs is the page submits the details it's holding to the server and expects the login result as a response.
Javascript should have worked and I don't know why it didn't, I added a script to change some of the UI elements upon submission of the form, but it seems the OnPostAsync method in the PageModel was being called first and whether the script was running or not it just wasn't updating the UI, I'm guessing because it's awaiting the response before doing anything. The alternative was to remove the login code from the PageModel and use an AJAX call instead, but I didn't really want to do this.
I've added an ILoginHandlerService, with a StoreLogin and RetrieveLogin. In the implementation it receives a login object containing the credentials, encrypts them and stores them in a private variable. This service is added as a singleton in the app startup class. The login page now calls the StoreLogin method with the submitted details, and redirects to a new "Logging in" page. This new page has a "form" with just a text element containing a please wait message, and a script which calls Post on the form upon loading.
The "Logging in" page's OnPostAsync is what actually performs the login. It calls upon an injected IAuthService to log in, without passing any details to it. The IAuthService implementation itself (added as a scoped service in app startup) gets injected with the ILoginHandlerService, then internally calls upon that service to supply the stored login object. The stored object is decrypted, nulled and returned to the IAuthService and is then submitted to my API, which then responds with the logged-in user token, that is returned to the "Logging in" page, which then calls upon HttpContext.SignInAsync, adding the received API token, and redirects the user to the home page, signed in.
This seems very convoluted to me and I'm not entirely sure it's correct. From what I understand of the above, once the credentials are submitted from the login form all future processing of the credentials should now be done server side and are never returned back to the client?
I am using Meteor accounts core package to create new users and send them verification email, but I am facing a problem as when I call Accounts.createUser from server side as a method, no verification email is sent, however if I called Accounts.createUser from the client side new accounts are created and a verification link is sent to the client...can someone please tell me what I might be missing / doing wrong here? Thanks
Accounts.createUser({email: adminData.email, password : adminData.password});
So some clues and tips. Normally Accounts.createUser will not sent out verification emails and that it does that in one case (client side) and not in the other case (server side) is a little strange. Normally it would only sent out verification emails when you have
Accounts.config({
sendVerificationEmail: true
});
on the server side (see http://docs.meteor.com/#/full/accounts_config). So first you should check that and maybe that already solves your problem.
When this isn't set the only other way an verification email got sent out should be calling Accounts.sendVerificationEmail (see http://docs.meteor.com/#/full/accounts_sendverificationemail) but this is only possible server side. So to make use of that client side you would need to write a server side method with it and call that via Meteor.call from the client side. However if you can't find your problem you could also use that to work around it by using Accounts.sendVerificationEmail within Accounts.onCreateUser (see http://docs.meteor.com/#/full/accounts_oncreateuser) on the server side. Or after you call Accounts.createUser server side as at that point you already know the users email address and the account already got created so that should work really well.
Oh and obviously the email package needs to be installed (http://docs.meteor.com/#/full/email) but as some mails already get sent out I guess that's the case.
Original post:
This web application sends out emails which contain a link to a URL.
Correction-Clarification 9/17/2014:
An .EXE running as a scheduled task on a server (in "support" of the web app and connecting to same database) sends out emails which contain a link to a URL.
The nature of the email content is essentially a "reminder"; the link when clicked is essentially an acknowledgement signaling "done".
Resumption of original post follows:
Clicking the link in the email does 2 things at the target .ASPX page:
the page logic updates a database and sends another email to the same user
the page finishes by displaying a "success" message in the browser
Would it be bad design to eliminate the success message sent by the browser?
I'm thinking the opening of the web page just to announce "success" is not needed. If the target URL were replaced with something with no user interface (e.g. HTTPHandler, webservice) then I'm thinking the email sent back to the same user confirming "success" would be adequate.
Yet, part of that approach "feels awkward", I guess because normally clicking on links in emails causes web pages to open. Given these requirements, would this be bad design to eliminate the browser?
UPDATE - 10-17-2014:
see: Submit to HttpHandler results in RequestType GET instead of POST
update below
Actually, it's bad design to have a state change occur based on a GET request. A number of email systems (and virus scanning software) will follow the link in order to determine whether it should be quarantined or not.
Never mind that a GET request causing a change in state is pretty much against how the web is supposed to work anyway.
What should happen is they click the link, then the mail program opens the browser. You then show a page asking them to confirm the action by clicking a button. That buttons makes a POST request which you then act on.
Finally, I'm not entirely sure how you would eliminate the browser anyway. The mail program detects that it's a link and opens the browser once the user clicks on it. This is no different than how things like opening word documents or zip files. The email program just asks the OS what program is supposed to handle the action and passes it off to that program.
With your update, I think there's a much cleaner way. However this is dependent on the capabilities of the email client that'll be receiving the messages. Should be good for the vast majority of them.
In the body of the email, instead of sending a link, include an HTML form that contains a button which performs a postback to your server. See this ( link ) for samples of how some other companies have done it.
This way the action is a single step instead of two AND you aren't doing things the Wrong Way(tm).
Users need to fill out an access request and once they are done and hit the submit, it emails the request to their supervisor.
Is it possible to email the entire form(with the user data and also to be filled fields by supervisor) in an email so that the supervisor can select accept and the change would be reflected in a SQL database from Outlook itself?
Emailing the form can be done. Writing an Outlook add-in can also be done. But you'll save yourself a lot of time if you just write an "approval" page in your web app and send a link to this page in the email to the supervisor. You can put any information you want in the email, of course.
ETA: But to actually suggest a solution: you could send an email that included a hyperlink, that included identifying information in the query string, and use that as a way of signalling to a web page or web service that the request should be approved. You'd have to work out something with security and authentication, of course, so that not just anybody could call that page and approve the request.