I'm running Django on an Apache server on Ubuntu and the activation of a new account via a link in an e-mail fails sometimes. I've checked my access logs and I can see that the activation link is opened by an EC2 server (whois lookup gives an AWS resource, IP is not the public IP of my own server). Any ideas who/what this could be? I have TLS enabled in settings.py for sending emails: EMAIL_USE_TLS = True.
So the reason for failing the activiation is because the link is already openend, but I'm worried what happens there. I've seen this happening 3 times with completely different user agents for 3 completely different account-activations but from the same IP address.
The first thing that came to my mind is that maybe an e-mail client is opening the links to generate a preview? Like, to show a screenshot when the user hovers the link.
Why do you make links usable once? You can use a token that is valid until the account is actually activated (and disable the link if the account is not activated for a certain amount of time).
Related
I've deployed a django website with Heroku. When a user creates an account in the app, a validation email is supposed to be sent. Do do that, I'm using smtp from gmail, and in my account settings, I've activated "less secure app access".
This works perfectly fine on my local machine, but when using the deployed app, I can't get the email to be sent.
The first time, I got a security warning from google saying someone connected to my account. I said it was me and tried again. I didn't get any other security warning but it seems the app is still unable to send emails.
Please, let me know if you have any idea what the issue might be.
Thanks.
Recently discovered in our Google Admin Portal that: Per User outbound Gateway is turned on, checking with other people I work with, no one knows why its turned on and when it was turned on.
I have been digging through the Google admin sdk and have not found a way to check to see if any users is using this setting.
In short, does anyone know how I can check to see if a user in our domain has a secondary smtp connection or a "Send Mail As" option in use?
So, the setting 'allow per user outbound gateway' does indeed give users permissions to add a 'From' address external to your domain. However if anyone is using this, they'll likely need to configure it as a send-mail as address inside Gmail.
You can list all 'Send as addresses' via the Email settings API as per https://developers.google.com/admin-sdk/email-settings/#retrieving_send-as_alias_settings. Note that the code examples provided will not work as they're out of date and showing client Login which has been disabled for months now. I'd be advising you to Auth with Oauth 2.0, call the endpoint with wget or CURL(probably wget since recursive)
I host an Facebook application (https://apps.facebook.com/igoaltip/) on AppFog. Suddenly it stopped working. When I try to get information about the user using user access token (https://graph.facebook.com/me), Facebook returns OAuthException (#5) Unauthorized source IP.
I use Node.JS on server with facebook-node-sdk.
I do not specify IPs in server IP whitelist.
In Heroku, i've had the same issue, and a simple restart solved my problem!
Currently experiencing the same issues on Appfog regarding Facebook requests. AppFog might have received a block from Facebook.
We added the US east IP's of appfog to our whitelist, but for more then half an hour we still receive the same error. Stangely enough we can still use the apps tokens from other IP's. This causes me to believe it takes quite a while for Facebook to enforce the whitelist
Send a support ticket to support#appfog.com and they will help you with getting your app whitelisted with Facebook. Put Facebook and Whitelist in the subject.
According to appfog, it's something they need to take care of, you can only work around it by cloning apps, which for me isn't a solution for SoA architectured app
Source: https://groups.google.com/forum/m/#!topic/appfog-users/K4UCWhvxGZU
I'm running the WSO2 Stratos VMware image, and I have it to the point where it's running, I've got the browser open, it's at my internal deployment of WSO2, and I've created an account for myself. The problem is, the VM isn't networked to anything, so when it tells me it sent an email to my account and would I please validate it, I can't validate it because it never actually sent an email. I thought maybe there'd be a local mail server on the Linux guest, but I couldn't find one.
Am I missing something? Do I even need to validate the account? I can't seem to access any of the Stratos services, and I suspect that the account validation has something to do with that.
You can log in as an administrator (with the default username/password: admin/admin) and activate the tenant/account you created.
We're having a hard time figuring how these credentials objects work. In fact, they may not work how we expected them to work. Here's an explanation of the current issue.
We got 2 servers that needs to talk with each other through webservices. The first one (let's call it Server01) has a Windows Service running as the NetworkService account. The other one Server02 has ReportingServices running with IIS 6.0. The Windows Service on Server01 is trying to use the Server02 ReportingServices WebService to generate reports and send them by email.
So, here's what we tried so far.
Setting the credentials at runtime (This works perfectly fine):
rs.Credentials = new NetworkCredentials("user", "pass", "domain");
Now, if we could use a generic user all would be fine, however... we are not allowed to. So, we are trying to use the DefaultCredetials or DefaultNetworkCredentials and pass it to the RS Webservice:
rs.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials
Or:
rs.Credentials = System.Net.CredentialCache.DefaultCredentials
Either way won't work. We're always getting 401 Unauthrorized from IIS. Now, what we know is that if we want to give access to a resource logged as NetworkService, we need to grant it to DOMAIN\MachineName$ (http://msdn.microsoft.com/en-us/library/ms998320.aspx):
Granting Access to a Remote SQL Server
If you are accessing a database on another server in the same domain (or in a trusted domain), the Network Service account's network credentials are used to authenticate to the database. The Network Service account's credentials are of the form DomainName\AspNetServer$, where DomainName is the domain of the ASP.NET server and AspNetServer is your Web server name.
For example, if your ASP.NET application runs on a server named SVR1 in the domain CONTOSO, the SQL Server sees a database access request from CONTOSO\SVR1$.
We assumed that granting access the same way with IIS would work. However, it does not. Or at least, something is not set properly for it to authenticate correctly.
So, here are some questions:
We've read about "Impersonating Users" somewhere, do we need to set this somewhere in the Windows Service ?
Is it possible to grant access to the NetworkService built-in account to a remote IIS server ?
Thanks for reading!
All details you need are included in this very old article
In short, when you find it confusing to troubleshoot issues like this, you should first review the technical details behind ASP.NET impersonation carefully.
Here are some things you could check out:
- set an SPN (Service Principal Name) for the reporting service; you can find good examples in google;
- Allow delegation (ClientCredentials.Windows.AllowImpersonationLevel)
Is the problem that you're failing to authenticate to IIS, or failing to authenticate to SSRS? The DOMAIN\MachineName$ account may need to be granted permission in SSRS to run the report you're trying to automate.
SSRS usually does a pretty good job of getting IIS configured correctly, so you shouldn't need to mess with those settings. I double-checked my installation (which is SSRS 2005, things may have worked differently in SSRS 2000 and you didn't say which version you're running), and it's set to use Windows authentication and has impersonation enabled. That means IIS should basically just be authenticating your credentials (validating a correct username/password), not authorizing (determining whether that user has permission to run the report in question). IIS then passes the credentials on to SSRS, which has its own settings for determining what accounts have permission to view reports.
Also, you can automate sending reports on a scheduled basis directly in SSRS, so you may not need the Windows service at all if your scheduling is fairly basic (i.e., daily, weekly, etc.).