I'm running OpenBD CFML isValid('email','something#whatever.education') and my result is 'NO'.
.education is a valid domain - why does this fail?
It turns out to be an issue with the regex used behind the scenes to match valid domains.
The regex in place didn't account for domains as long as "education".
I fixed it and it's been merged, should be in the nightly by now, grab the latest update and you should be able to use isValid("email", "AwesomeEmail#School.education") just fine. Viva la open source.
Related
I'm trying to get emoji's from a another server.
I creates a server object for the server, it is a constant because I want to only pull from this server.
for emoji in main_tuple:
emoji_name_id =await server.fetch_emoji(emoji)
emoji_array.append(f"<{emoji_name_id.name.lower()}:{emoji_name_id.id}>")
error:
nextcord.ext.commands.errors.CommandInvokeError: Command raised an
exception: NotFound: 404 Not Found (error code: 10014): Unknown Emoji
I should mention I want to display it another server, I know this is probably obvious but yeah.
main_tuple is a directionary in a database that has the emoji id and name.
the error
Also the bot is part of the server it's getting the id from.
I have looked at: discord.py emoji all servers bot in
and it does not work for me.
First Issue, you are making a wrong reference.
<:Name:ID> and not <Name:ID> (if you don't see it, you missed the first colon)
Another issue,
emoji_name_id.name.lower()
Custom emojis are to have to have 'exact' name and ID as they have, by using lower method, you would be trying to reference a wrong custom emote.
For example:
The actual emote which might have the following reference <:ThisIsACoolEmote:ID>, while you are appending <:thisisacoolemote:ID> which doesn't exist
To mitigate this, you can just append str(emoji_name_id) which will automatically give you the correct emote reference which is in the format <:Name:ID:> and yes, it also will format animated emojis too, i.e:<a:Name:ID>
also fetching here might not be the best practice, you can use bot.get_emoji instead which gets emote from internal cache if you have access to member Privileged Intent.
My company has an app that currently only validates by looking for the '#' in the email address. The app is being upgraded to support other cultures and written language use-cases. I suggested using regex code from Microsoft that validates the addresses using regex. They don't see the need to use the regex version if checking for '#' works. My question here is... What pitfalls exist if the validation isn't good enough. Meaning the email server will not be able to send the emails if they have the '#' but fail other checks. What can go wrong?
The list can be quite long:
1#2
do#home
why#home¬#boooom
iAm#...
#where
#homeIsaid
NoYouAreNot#home
....#......
and so on.
All of these are mistakenly valid email addresses if you only check for #
That said, it's worth mentioning coming up with an email address regex that works can be quite difficult. See this
It's cleanup time.
I'd like to cleanaup my mails. Therefore it would be nice to have all emails sorted/grouped by domains (optionally by TLD's as well).
I'm already using something similar - the field for the sender's email adress, which was described at https://www.howto-outlook.com/howto/viewsenderaddress.htm, which works perfectly. So I think something similar can be done for the domain (and TLD) as well.
Has someone here either a working solution ans share it or guide me how to achieve this.
Thx.
Remarks:
It's Outlook 2007 without Exchange
Thanks to a big search engine when using the proper words solution can be found. :-)
I have found a solution which displays the Senders Domain: https://www.extendoffice.com/documents/outlook/2190-outlook-view-sender-domain.html
and to Sort and Group on the Domain use
https://www.extendoffice.com/documents/outlook/2187-outlook-sort-group-by-sender-domain.html
I'm using DotNetKit 1.2.6.5 and SagePayIntegration.Validation() is rejecting a customer email that uses the new .online domain (eg: foo#bar.online) with
CustomerEMail is invalid.
Is this fixed in 1.2.6.7 or is the source code for SagePay.IntegrationKit.DotNet.dll available somewhere so I can fix it?
Despite access to the source code (many thanks to #DavidG) SagePay Support have confirmed that the actual Gateway does not support all these new domains - so even if I modified the DotNetKit it would still be rejected by the Gateway.
SagePay support were very helpful but ultimately the
"... email domain foo#bar.online is not yet supported on our gateway.
We run development sprints continuously and although there are some
domains we may not yet support, we look to in future, dependent on
impact and demand..."
The SagePay Integration Kit uses this regex to validate email addresses:
[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+)*#(?:[a-zA-Z0-9](?:[a-zA-Z0-9-]*[a-zA-Z0-9])?\.)+(?:[a-zA-Z]{2,4})\b
Which does unfortunately not allow extra long TLDs. Fortunately I have the source code for the kit and I've added it to my GitHub account (along with a bug fix which is why I had to get it in the first place as SagePay are not updating it). You can find it here:
https://github.com/WiredUK/SagePay.IntegrationKit
And the Regex you need to edit is this file:
https://github.com/WiredUK/SagePay.IntegrationKit/blob/801f61cf965c391a98a025aa632949719084cef0/ApiRegex.cs
For info, you need to edit the very last part of the expression from 2,4 (which matches 2 to 4 characters in the TLD) to allow more, for example 2,30.
Edit: And just because I can, I opened an issue and fixed it.
In an MVC framework, I have a model with an "identifier" field. This field can be whatever is used by the user as their unique identifier. I then use this identifier field in URLs to access the relevant resources.
/people/<identifier>/
In one such case, the user is using identifiers of the format 00/000. The quick among you will have spotted the problem straight away - how do we know which part is the identifier, and which part the action?
The obvious solution is to use URL escaping (%2F being the relevant code). However, this confuses my apache load balancing proxy as well as the application server on our demo box (running passenger). Although annoyingly this works fine on the local development servers. URLs including %2F seem to cause 404 errors from the server (not the application!).
What i'm looking for is a general approach to solving this problem, while keeping a tidy URL.
The stack which caused this problem is: Ruby 1.8.7, Merb 1.0.12, Apache load balancing to a thin cluster on production, Passenger on the demo server, and working with unproxied thin on development.
The cleanest way would be to prevent the user from entering in a forward slash character in the first place. If it is necessary to support this format, then there is no way around having to use URL escaping.
You could always use a home-grown encoding that replaces / with some other character that is never used in your identify field and then converts it back when reading it from the URL.
For example:
http://yoursite/people/00/000
becomes
http://yoursite/people/00-000